Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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)?

share|improve this question

9 Answers 9

up vote 7 down vote accepted

How about http://cr.yp.to/daemontools.html?

share|improve this answer
    
+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 –  Stefan Lasiewski Aug 20 '10 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 Aug 22 '10 at 9:08

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

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

share|improve this answer

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

share|improve this answer

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.

share|improve this answer

respawn in inittab

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.