32
For recent Ubuntu versions (12.04+), simply use
console log
And the daemon output (STDOUT & STDERR) will be appended to /var/log/upstart/<service>.log
http://upstart.ubuntu.com/cookbook/#console-log
29
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:
respawn
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-...
19
systemd script for starting my app server - Unknown lvalue 'StartLimitIntervalSec' in section 'Unit'
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 ...
12
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 ...
10
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 ...
10
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 ...
9
I came across this similar situation and it was because the port was already used by another service.
How I found it out ?
Try running
sudo nginx
rather than starting it as a service and it should display the error message.
8
I have manually stopped all my important services like LDAP, PostgreSQL and MySQL. And I did run:
reboot -f
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-...
6
Workaround: Rename the the foo service to foo2...
See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=582745
6
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.
5
This is what I did (CentOS 6, Upstart 0.6.5) to debug respawn issues. In a different terminal, do
sudo initctl log-priority debug
sudo tail -F /var/log/messages
5
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
respawn limit ...
5
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 ...
5
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-...
4
According to the upstart cookbook/intro linked here, upstart will emit a 'filesystem' event when all mounts are completed. You should be able to "start on filesystem" the required service to achieve what you're looking for, unless you're only wanting certain (but not all) filesystems to be mounted prior to service invocation?
4
This is because, on Ubuntu 15.04, /sbin/init is NOT Upstart.
Upstart is at /sbin/upstart.
By default, 15.04 is using Systemd instead of *Upstart *.
You should look into creating a Systemd unit file instead.
See: https://wiki.ubuntu.com/SystemdForUpstartUsers
3
I have done an improvement to Roger answer. Typically you want to backoff when there is a problem in the underlying software causing it to crash a lot in a short period of time but once the system has recovered you want to reset the backoff time. In Roger's version the service will sleep for 60 seconds always, even for single and isolated crashes after 7 ...
3
I've posted an answer to Bradd's question on AskUbuntu: https://askubuntu.com/a/490900/297973. Long story short, you may need to add $KLogPermitNonKernelFacility on to rsyslogd's config.
3
I tend to use eval $(cat /etc/environment | sed 's/^/export /')
It takes each line in /etc/environment, prepends export, and evaluates it:
script
exec /bin/bash <<'EOT'
eval $(cat /etc/environment | sed 's/^/export /')
do_what_you_need_to
EOT
end script
3
This question seems to contain a lot of sub-questions about how to handle environment variables in an Upstart script, so I thought I would share a few things I do to handle and test my environment for Upstart and Cron.
The first thing to know about Upstart, and the like, is it does not share the same environment as your active terminal, so something like:
$...
3
Building on the accepted answer (and since I do not have enough rep to comment on it)
Respawn is NOT a mongo configuration parameter, it is for the upstart service configuration file.
respawn
respawn limit 10 90
Digital Ocean has a nice tutorial for using upstart and systemd (newer).
https://www.digitalocean.com/community/tutorials/how-to-configure-a-...
3
When /var/log/upstart/api-access.log is archived the original filesystem link to it is removed, however the inode remains as it's being held by the exec-ed process. The process continues to write to this inode even while there is no reference to it and will continue to do so until the process is restarted.
Unless there a particular reason you are ...
3
One way to solve this is to change the order that these things load by modifying the order the init script calls them. There may be other (easier) ways to do this, but the bare metal way would be to -
Find the runlevel the server is running on by issuing the command (as root) "runlevel".
Go to /etc/rcX.d where X is the runlevel number you are in.
You will ...
3
Looks like everything works like upstart is supposed to (I had put my files in the wrong directory!):
I just did the following:
echo "manual" > /etc/init/atd.override
and voila -- the atd process no longer starts up on reboot!
3
You can enable debugging to the system log with the initctl log-priority <priority> command.
To change the priority with which Upstart logs messages to the system
log, you can change the log priority at any time using log-priority
command as follows:
initctl log-priority <priority>
Where <priority> may be one of:
debug, ...
3
sudo persists as long as the process is running, so the solution is to use the setuid and setgid stanzas of upstart. The problem with that is that the line that sends the PID of the daemon needs root privileges. Here is a workaround:
[name].conf:
start on runlevel [2345]
stop on runlevel [016]
env HOME=/home/deploy
env NODE_ENV=production
setuid deploy
...
3
sudo is not the right tool for anything regarding init systems. please avoid using it if possible.
setuid and setgid affect all stanzas of the upstart job, including the pre-start.
This can easily be worked around with the following job, my-service-prep.conf:
start on starting my-service
task
PIDDIR=/var/run/my-service
exec install -o my-user -g my-group ...
3
If you press F5 in htop you see the process hierarchy, which helps explain what you're seeing here.
They're probably ordered like this 586 -> 677 -> 1077 -> 1082.
586 'su' - spawns
677 'export ...; cd ...; thin start ...' which spawns
1077 'thin start ...' which spawns
1082
3
On RHEL 6 to respawn a script, go to /etc/init and create a file
cd /etc/init
vi scriptFileName.conf
And add this content
start on stopped rc RUNLEVEL=[12345]
stop on runlevel [!12345]
respawn
exec /you/respawned/script.sh -your -parameters
Save file and then launch this command (without .conf of file)
start scriptFileName
Thats all!
3
My understanding of the Vagrant boot sequence is that Vagrant mounts /vagrant (and any other shared filesystems you have defined) using SSH, after the boot sequence has completed.
As such, you'll probably want to run systemctl start my.service in a provisioner, with run: always specified, so the provisioner runs on every boot, not just when the VM is ...
Only top voted, non community-wiki answers of a minimum length are eligible