Nginx reload problem

[B.R.]

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.

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.
​


> 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?
​

​Thanks,​

---
*B. R.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130817/a338410d/attachment.html>