Nginx reload problem

[Maxim Dounin]

Hello!

On Sat, Aug 17, 2013 at 12:07:22AM -0400, B.R. wrote:

> Hello Maxim! :o)
> 
> 
> On Fri, Aug 16, 2013 at 11:16 PM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> >
> > On Fri, Aug 16, 2013 at 10:16:16PM -0400, B.R. wrote:
> >
> > > I guess it would be nice if the doc warned about directives that need a
> > > server restart to be reloaded.
> > >
> > > Everyone supposes (as it seems obvious) that reloading Nginx is enough to
> > > apply configuration changes.
> >
> > Reloading is enough.  What is very wrong is to assume that sending
> > a HUP signal to nginx is enough for a reload.  For various
> > reasons, ranging from configuration syntax errors to out of memory
> > problems, configuration reload might fail.
> >
> > Quoting documentation:
> >
> > ... If this fails, it rolls back changes and continues to work
> > with old configuration. ...
> >
> > http://nginx.org/en/docs/control.html#reconfiguration
> >
> 
> ​​Yup I knew that. I thought Nginx was able to re-arrange its memory
> allocation for the new variable.
> I didn't know it was keeping the same fixed memory​, only replacing
> existing values.
> 
> I saw on some init script on CentOS (probably with the packaged version of
> that OS) that the configuration check was invoked automatically when the
> service reload was called.
> That would be a nice improvement to the init script shipped with the
> official Nginx package (from nginx.org) to avoid a manual 'nginx -t' call
> before the reload.

I don't think that calling "nginx -t" as a mandatory step before 
configuration reload is a good idea: nginx binary running and 
nginx binary on disk might be different, and "nginx -t" result 
might be incorrect because of this, in some cases rejecting valid 
configurations.

Additionally, it does duplicate work by parsing/loading a 
configuration which will be again parsed by a master process 
during configuration reload.  While in most cases it's not 
significant, I've seen configurations taking more than 1m to load 
due to big geo module bases used.

> > > An interesting part of the question was the inquiry about the potential
> > > existence other directives requiring a server restart rather than its
> > > reload. Do you have intel on this Maxim?
> >
> > There are no directives which require a server restart.  But some
> > changes are not possible on the fly - e.g. you can't change a
> > shared memory zone size.  If you want to change it - you have to
> > create another shared memory zone, or use a binary upgrade which
> > doesn't inherit shared memory zones and their contents (or use a
> > restart, which will obviously work as well).
> >
> 
> ​That reminds me that the init script shipped with Nginx doesn't take
> advantage of the 'hot binary switch'​
> 
> ​to provide a 'soft restart' without downtime.
> It clearly would be a nice alternative to the normal restart which is
> basically a stop/start.​

There is the "upgrade" command in the init script shipped with 
nginx.org linux packages.

-- 
Maxim Dounin
http://nginx.org/en/donation.html