I started hosting sites a while back using Cherokee. For external sources (FastCGI, etc) it has an option to launch the process if it can't find one running on the designated socket or port. This is great because it means if PHP or a Django site falls over (as they occasionally do) it restarts it automatically.

On a new server using PHP-FPM I couldn't use Cherokee (it has a bug with PHP) so I've moved to NGINX. I really like NGINX (for its config style) but I'm having serious issues with processes falling over and never respawning. PHP does this sometimes but Django sites are more of a problem. I've created init scripts for them and they come up on boot but this doesn't help me if they conk out between reboots.

I guess I'm looking for a FastCGI proxy. Something that, like Cherokee, knows what processes should be running on which sockets/ports and respawns them on-demand. Does such a thing exist? Is there any way to build this into NGINX (for ease of config)?

9 Answers 9


How about daemontools and specifically the supervise tool

supervise monitors a service. It starts the service and restarts the service if it dies. Setting up a new service is easy: all supervise needs is a directory with a run script that runs the service.

  • +1 for daemontools. However, you often can't just throw a script like /etc/init.d/apachectl into it. You often need to rewrite your own simple startup script to use exec. Although I would love to see some more examples using daemontools Commented Aug 20, 2010 at 18:33
  • daemontools has another incarnation as runit. Not so important now that daemontools is public domain, but an older distro may only have runit.
    – camh
    Commented Aug 22, 2010 at 9:08

respawn in inittab


I second the daemontools suggestion, but if you don't like the way DJB's software works (for whatever reason), there's also supervisord.

I set up a FreeBSD image a while back that used supervisord to manage nginx and gunicorn, which I used to host some simple WSGI apps, and the whole process was pretty straightforward.

If you're doing this for Django, Gunicorn makes it really straightforward to deploy Django apps, btw. See this blog post for more details.


Another option could be to use monit, which is the one I generally use.


Have you considered god?

God is an easy to configure, easy to extend monitoring framework written in Ruby.

Keeping your server processes and tasks running should be a simple part of your deployment process. God aims to be the simplest, most powerful monitoring application available.

I use it to make sure that if Rails/nginx instances fall over, they get revived, and although I don't see built in support for checking if it's using the right port or not, but if the problem is that the process fails or is no longer running, you can't go wrong with god.


In addition to daemontools and supervisord, there's daemonize.


A hackish solution would be to periodically launch a script (via cron) that detecs if the process is down, and in this case relaunch it.


There are various ways to restart a failed daemon, the usual recommendation is "respawn in inittab" but with some consideration of a limit if the machine is really screwed.

The watchdog daemon can also monitor a process via its PID file. However, that should only be considered as a secondary line of defence to reboot a machine that is too sick to run properly (e.g. out of memory, fork-bombed, etc), and not as a primary way or monitoring and restarting a daemon.

Finally you can consider monitoring complex systems using nagios to provide the administrator(s) with a global view. It can run plug-ins to probe the operation of the daemon externally, which is a more complete test of its functioning that simply the PID being live.


Simple answer - start, write your pid somewhere, and every x time (seconds, minutes, your bet) check if the process is up.

Long answer - all of the above are good methods. But somewhat complicated.

Also keep in mind that being alive and answering to requests are different things.

  • 1
    … and cross your fingers and hope that nothing scribbles over the PID file, or erases it, or re-uses it for a different daemon, or re-points it at some other innocent and unrelated process that won't react well to the check for being up. ☺ Which is why the long answer of a proper daemon supervisor that runs daemons as child processes and monitors them with the usual Unix/Linux system mechanisms is the long-accepted better way.
    – JdeBP
    Commented Jan 4, 2015 at 18:47

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .