daemon off in production

[Igor Sysoev]

On Sat, Sep 17, 2011 at 02:49:03PM +0400, Igor Sysoev wrote:
> On Sat, Sep 17, 2011 at 07:40:19AM +0300, Yaniv Aknin wrote:
> > Hi,
> > 
> > The documentations says I should never run nginx with the daemon off setting
> > in production. I would like to do so anyway so my Python/twisted based
> > process manager will have an easier time knowing if nginx terminated or not
> > (I know there are other ways to do it, but this seems like the easiest; if
> > I'll be forced to, I'll use another way).
> > 
> > I'm aware of SIGWINCH and nginx in general and especially after version
> > 1.1.1, and I don't mind taking care of guaranteeing nginx will run without a
> > controlling terminal (I will fork()/setsid() before exec()ing it), run in a
> > sensible current working directory, etc. I just don't want it to do the
> > daemonizing double fork.
> > 
> > From skimming the code, it appears to me that nothing bad should happen.
> > What am I missing? Why is it so bad to run nginx in the foreground in
> > production?
> 
> There are two directives: "master_process on|off" and "daemon on|off".
> Both are used to simplify nginx development: while testing a bug/feature
> I usually run nginx in foreground without master process and simply
> press ^C to stop nginx. This is an analog of Apache's -X command line switch.
> I did not want to type it in commanf line, so these two directives
> have been introduced.
> 
> There was thought to allow nginx to run in single process mode in production
> as many lightweight server do. So there is some incomplete code to support
> this fucntionality. But this code is incomplete, so you should never
> use "master_process off" in production.
> 
> As to "daemon off", I did not intend to use it in production (and never did),
> but many people do it. I believe it is safe to use "daemon off" in
> prodcution. You can apply SIGWINCH fix using:
> 
> http://trac.nginx.org/nginx/changeset/4020/nginx

The single option that is not available in "daemon off" mode is online
upgrade, because after the upgrade you supervior can not control new
nginx instance.


-- 
Igor Sysoev