5 messages in ru.sysoev.nginxRe: runit and nginx
FromSent OnAttachments
Chris McGrathFeb 20, 2007 5:35 am 
Igor SysoevFeb 20, 2007 5:58 am 
Chris McGrathFeb 20, 2007 6:10 am 
MikeMar 4, 2007 12:24 pm 
Igor SysoevMar 4, 2007 1:00 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: runit and nginxActions...
From:Igor Sysoev (is-G@public.gmane.org)
Date:Mar 4, 2007 1:00:15 pm
List:ru.sysoev.nginx

On Sun, Mar 04, 2007 at 08:24:59PM +0000, Mike wrote:

Igor Sysoev wrote:

On Tue, Feb 20, 2007 at 01:36:10PM +0000, Chris McGrath wrote:

I'm using runit to supervise nginx, and to get it to work properly, I had to set

daemon = off;

In the nginx.conf. The documentation says that this shouldn't be used in production. I was wondering why this was and if it is safe to keep running like this.

The "daemon off" and "master_process off" were initially created for development only. However, some people started to run nginx under daemontools and so on using "daemon off". Non-daemonized nginx runs without problems except you can not do online upgrade.

But "master_process off" should be never used in production.

Is there any way that this can be changed in the future? Non-disruptive upgrades to nginx are an awesome feature that we would love to exploit, but we are also using Runit to handle the service (and Launchd is handling Runit).

It's the technical issue. Runit fork()s and exec()utes nginx so it becomes the parent of the nginx master process. But when nginx does an online upgrade, the master process fork()s and exec()utes a new binary too. When old master process exists, the new master process' parent is init process (#1) and Runit can not control it.

The possible workaround is to use SO_REUSEPORT for listen sockets, but I did not investigate it.