I have a python script that'll be checking a queue and performing an action on each item:
# checkqueue.py while True: check_queue() do_something()
How do I write a bash script that will check if it's running, and if not, start it. Roughly the following pseudo code (or maybe it should do something like
ps | grep?):
# keepalivescript.sh if processidfile exists: if processid is running: exit, all ok run checkqueue.py write processid to processidfile
I'll call that from a crontab:
# crontab */5 * * * * /path/to/keepalivescript.sh
Avoid PID-files, crons, or anything else that tries to evaluate processes that aren't their children.
There is a very good reason why in UNIX, you can ONLY wait on your children. Any method (ps parsing, pgrep, storing a PID, ...) that tries to work around that is flawed and has gaping holes in it. Just say no.
Instead you need the process that monitors your process to be the process' parent. What does this mean? It means only the process that starts your process can reliably wait for it to end. In bash, this is absolutely trivial.
until myserver; do echo "Server 'myserver' crashed with exit code $?. Respawning.." >&2 sleep 1 done
The above piece of bash code runs
myserver in an
until loop. The first line starts
myserver and waits for it to end. When it ends,
until checks its exit status. If the exit status is
0, it means it ended gracefully (which means you asked it to shut down somehow, and it did so successfully). In that case we don't want to restart it (we just asked it to shut down!). If the exit status is not
until will run the loop body, which emits an error message on STDERR and restarts the loop (back to line 1) after 1 second.
Why do we wait a second? Because if something's wrong with the startup sequence of
myserver and it crashes immediately, you'll have a very intensive loop of constant restarting and crashing on your hands. The
sleep 1 takes away the strain from that.
Now all you need to do is start this bash script (asynchronously, probably), and it will monitor
myserver and restart it as necessary. If you want to start the monitor on boot (making the server "survive" reboots), you can schedule it in your user's cron(1) with an
@reboot rule. Open your cron rules with
Then add a rule to start your monitor script:
Alternatively; look at inittab(5) and /etc/inittab. You can add a line in there to have
myserver start at a certain init level and be respawned automatically.
Let me add some information on why not to use PID files. While they are very popular; they are also very flawed and there's no reason why you wouldn't just do it the correct way.
PID recycling (killing the wrong process):
/etc/init.d/foo start: start
foo's PID to
bar) takes a random PID, imagine it taking
foo's old PID.
/var/run/foo.pid, checks to see if it's still alive, finds
bar, thinks it's
foo, kills it, starts a new
PID files go stale. You need over-complicated (or should I say, non-trivial) logic to check whether the PID file is stale, and any such logic is again vulnerable to
What if you don't even have write access or are in a read-only environment?
It's pointless overcomplication; see how simple my example above is. No need to complicate that, at all.
By the way; even worse than PID files is parsing
ps! Don't ever do this.
psis very unportable. While you find it on almost every UNIX system; its arguments vary greatly if you want non-standard output. And standard output is ONLY for human consumption, not for scripted parsing!
psleads to a LOT of false positives. Take the
ps aux | grep PIDexample, and now imagine someone starting a process with a number somewhere as argument that happens to be the same as the PID you stared your daemon with! Imagine two people starting an X session and you grepping for X to kill yours. It's just all kinds of bad.
If you don't want to manage the process yourself; there are some perfectly good systems out there that will act as monitor for your processes. Look into runit, for example.