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 <[email protected]> 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 _______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
