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