Nginx reload problem

[Maxim Dounin]

Hello!

On Sat, Aug 17, 2013 at 12:36:38PM -0400, B.R. wrote:

> Hello,
> 
> 
> On Sat, Aug 17, 2013 at 7:37 AM, Maxim Dounin <mdounin at mdounin.ru> wrote:
> 
> > Hello!
> >
> > 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.
> >
> 
> ​​In that case, the server admin has a problem, since he has no way to test
> the configuration other the calling 'reload' on the running instance and
> check the logs for errors, hoping they are not already crawling under
> production-related log messages...
> One way or another, you test the configuration against an existing binary
> because you want to start or reload this binary with the conf. There is no
> point in having a running instance having already deleted its disk binary
> file: If you are in transition between 2​
> 
> ​versions of Nginx, you shouldn't also make big changes to the conf...
> That's a 2-steps procedures I'd say​: One thing at a time.

Making any changes to the configuration isn't something 
significant: even without changes at all new binary on disk might 
not consider an old configuration as a valid e.g. due to some 
module not compiled in.  And a reload might be required for 
various external reasons.

I don't say it's a normal situation, but it's possible, and 
proposed change to init script will prevent init script from 
working in such situation.

> Testing conf is of course a duplicate of work, but that's a safe operation.
> The command output will determine if your new configuration will work
> without having to carefully watch logs with anxiety.

As I already tried to explain, watching logs is required anyway.

> > There is the "upgrade" command in the init script shipped with
> > nginx.org linux packages.
> >
> 
> ​​Ok, so could Li have used the 'upgrade' command insted of 'reload' to
> reload the configuration and change the allocated memory?

Yes.

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