The Upstart Cookbook recommends a post-stop delay (http://upstart.ubuntu.com/cookbook/#delay-respawn-of-a-job). Use the respawn stanza without arguments and it will continue trying forever:
post-stop exec sleep 5
(I got this from this Ask Ubuntu question)
To add the exponential delay part, I'd try working with an environment variable in the post-...
You are likely comparing systemd docs you've read online for a different version instead using the docs on your system that match your version.
Check man systemd.unit on your own system. You may find that on your version, the directive is named
StartLimitInterval= and should be used [Service], not [Unit].
I found the answer by searching for systemd ...
The way you disable a service under just about any RedHat-derived distribution is with the chkconfig command:
# chkconfig httpd off
And to stop a running service:
# service httpd stop
These commands will Do the Right Thing regardless of whether your system is running systemd, upstart, or vanilla SysVInit.
For what it's worth, despite running upstart ...
So for some reason initctl likes it and service doesnt...
sudo initctl start test
test start/running, process 8776
A bug in EC2 Linux me thinks. My example exactly conforms to the documentation but no biggy to switch to using initctl
If you like to check which services are running you also can do this:
sudo initctl list
And to verify where the log error ...
I found the answer myself: the simplest way to achieve that is to add the following two lines at the end of the upstart script installed by MongoDB (/etc/init/mongodb.conf):
respawn limit 10 90
This will try to restart the process if it terminates, and stop if it crashes more than 10 times in 90 seconds.
I did not get the mkfifo trick to work satisfactorily; it did not seem to capture stderr, and attempts to redirect caused Upstart to bail with no errors.
It also has an unfortunate side effect of making the logger process hang around as a child of init, so the information about who "owns" the logger is lost, and anyone not already aware of the mkfifo might ...
When autossh invoked by sudo or init process, autossh use identity/ssh-keys file provided by root user (e.g. /root/.ssh/sshkeys). When you try run autossh from terminal, maybe you use non-root user. Thus, autossh use identity/ssh-keys file provided by that user (e.g /home/non-root/.ssh/sshkeys).
To get expected behavior, you can provided identity file in ...
Upstart does not support symlinks because they might point to a file on a partition that is not loaded at boot time.
I have gotten around this in my own project by putting the conf files in /etc/init/myscripts and then binding that to a directory in my repository. mount --bind /etc/init/myscripts ~/code/repo/initscripts.
Add this to /etc/fstab and the ...
I came across this similar situation and it was because the port was already used by another service.
How I found it out ?
rather than starting it as a service and it should display the error message.
I have manually stopped all my important services like LDAP, PostgreSQL and MySQL. And I did run:
The -f force parameter to ignore the init system. After the reboot I was able to make a simple reboot without force mode.
Another solution could be more agressive but useful to know, send a magic sysreq remotely with:
echo b > /proc/sysrq-...
From "man initctl"...
restart JOB [KEY=VALUE]...
Requests that an instance of the named JOB be restarted, outputting the status of
the job to standard output when the command completes.
The job instance being restarted will retain its original configuration.
To have the new instance run with the latest job configuration, stop the job and then start it ...
As of upstart v1.10.0 you can define a "reload signal".
This version is available on ubuntu as of v13.10 ... I used these instructions to upgrade my ec2 instance:
I use rails+puma and do graceful reloads with this directive in my /etc/init/app-1.conf ...
If an init.d script doesn't terminate, the normal system start-up will be interrupted indefinitely.
One common solution is to incorporate a counter in the while loop and exit with an error message after a given number of while loops. If you're waiting for an external command that doesn't have a timeout option, have a look at this question.
As already mentioned, use respawn to trigger the respawn.
However, the Upstart Cookbook coverage on respawn-limit says that you'll need to specify respawn limit unlimited to have continual retry behaviour.
By default it will retry as long as the process doesn't respawn more than 10 times in 5 seconds.
I would therefore suggest:
respawn limit ...
This is a write permission issue. User tomcat is not allowed to create a log file to a location where it tries to create them. The location it tries to create log files in differs depending on how you start tomcat.
This piece from from your log caught my attention:
java.io.FileNotFoundException: my-war.log (Permission denied)
description "Upstart script"
start on filesystem and started networking
FYI: don't use "start on startup".
stop on shutdown
# Let's make sure we always have the right directory
# Is there a reason you didn't do this?
The solution was not to run Celery beat together with the worker
(removing the -B part from the exec command).
Apparently this was the "extra" process, and was somehow messing things up.
Here's the final script I ended up with:
start on started postgresql
stop on runlevel [!2345]
kill timeout 20
Using chdir inside the script clause is plain wrong, and it means that you fail to understand a very basic idea in upstart (no offence meant). (As a side note, the exec keyword is just useless, but does no harm).
There is an idea very central to understanding how upstart works. Upstart tries to determine which process of the processes that were spawned by ...
I would say don't look at the current distro to determine which init system to use to manage daemons:
It's a little nebulous to determine a distro (as described in Dennis's answer)
the init system in use changes between versions of a distro (as Michael Hampton noted, the big name distros are all gravitating toward systemd; Ubuntu is currently the one big-...
It seems to me you're trying to bind postgres to an IP associated with the tunnel. If that's the case, the ip_nonlocal_bind is the solution to your problems. Setting the ip_nonlocal_bind allows you to bind to any IP, even one not associated with your computer, which is exactly what you want when you want to bind to an IP you don't yet have - for instance ...
You need a -N option so that is doesn't create an interactive shell.
exec sudo -H -u pi -s autossh -M 0 -N -R remoteport:127.0.0.1:localport email@example.com
From the man
-N Do not execute a remote command. This is useful for just forwarding ports
Don't bother with using any of the "advanced" features of upstart on RHEL6. It only uses upstart as a "replacement" for the original SysVinit, and only uses old-style init scripts. RHEL itself doesn't take advantage of any new upstart features, and RHEL7 does not include upstart. In fact upstart has pretty much been abandoned by everyone at this point except ...
Figure it out. Not sure I know how though.
I think it was the LOGTO portion of the uwsgi.conf file that made it not work. This is my uwsgi emperor file now:
description "uWSGI Emperor"
start on runlevel 
stop on runlevel [!2345]
exec uwsgi --emperor /etc/uwsgi/vassals/ --master --uid www-data --gid www-data --logto /var/log/uwsgi/emperor....
Disable the service you dont want to start during system boot using chkconfig.
List available services with their states
Disable service htttpd in runlevel 2345
chkconfig --level 2345 httpd off