4

I am rather confused about ensuring that nginx is always up. My understanding the init.d script justs start and stops nginx. Is this correct? Then in the docs its says to keep daemon = off;

Now, I would like to use runit and the below is my runit run script:

#!/bin/sh
exec /etc/init.d/nginx start

I notice that a new PID is always created.

So in sum: 1) I do NOT have this statement in the nginx file:

daemon = off;

2) I am using the above runit script but it always creates a new PID.

So...what is best practice to ensuring that nginx is always running.

I am using monit by the way but would runit to own hte daemon.

As a test, I did kill nginx using killall -9 nginx and I did a ps aux | grep nginx and noticed I got new pid's. So..do I still need runit?

Cœur
  • 37,241
  • 25
  • 195
  • 267
Tampa
  • 75,446
  • 119
  • 278
  • 425

2 Answers2

7

Scripts under /etc/init.d are associated with sysvinit, a venerable and unfortunately fairly broken approach to UNIX service management. See, processes under UNIX form a tree: every process has a parent, the process that started it. The parent has a lot of control over its children and importantly is notified when a child process dies. It's practically trivial to keep a process running or shut it down if you're its parent.

And there's the problem: a sysvinit service script starts a service and then exits, leaving the service running. The service's parent process is gone, which makes it difficult to locate and track the service - when a sysvinit script is asked to stop a service, it needs to figure out which process should be stopped, using unreliable information.

Under correct service management approaches, as used in runit and daemontools, services are run by supervising processes, which stick around after launching the service. Since the service is a child process, the supervisor process knows if it's running, if it's crashed, and where to find it to send it signals.

So in a runit script, the correct thing to do is to run nginx itself, not an init.d script. This is easy enough to do. However, by default nginx daemonises itself, which means it deliberately "escapes" from its parent process and becomes very hard to keep track of. Fortunately that behaviour can be switched off, which is the purpose of the daemon off; configuration option. A valid runit script for nginx therefore looks like this:

#!/bin/sh
exec /usr/sbin/nginx -g "daemon off;"

Short and sweet. runit can manage this arrangement very nicely - it'll keep nginx running, and you can control it with sv. For example, sv hup nginx tells nginx to reload its configuration. Of course, the PID will change if nginx crashes and is restarted, or if you deliberately ask it to restart with sv restart nginx, but runit will handle that just fine.

(Incidentally, never ever ever use kill -9, ever.)

00dani
  • 1,498
  • 15
  • 17
-4

Nginx has a master process that manages the worker processes. It keeps itself running. By making nginx run in the foreground and letting some other application manage is poorly reinventing the wheel.

MTeck
  • 1,642
  • 3
  • 16
  • 34
  • 3
    I don't understand this, how the master process can keep itself running in case it crashes? – Paolo Oct 01 '12 at 00:37
  • 4
    the whole idea of using dedicated supervision programs (like runit) is to not keep reinventing the wheel. On the positive note at least nginx provides non-stop upgrades with the help of its reinvention, so if you need it it might be a good idea. – squiddle May 02 '14 at 09:55
  • 1
    Using process supervision has nothing to do with the management of the child worker processes. The typical use of process supervision is to (a) forcibly keep a service up, even if it is faltering, (b) provide strict control of the service, so it can't "run away", and (c) provide much tighter control over logging, so that valuable log data isn't lost due to a crash. – Avery Payne Apr 16 '15 at 21:52