Nginx reload problem
mdounin at mdounin.ru
Sun Aug 18 19:14:56 UTC 2013
On Sat, Aug 17, 2013 at 12:36:38PM -0400, B.R. wrote:
> 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?
More information about the nginx