Hello, On Sun, Aug 18, 2013 at 3:14 PM, Maxim Dounin <[email protected]> wrote:
> > 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. > OK I think I got it. 'reload' deals with a running instance while 'upgrade' starts a new one from the binary on disk, so it makes sense to check the configuration against the binary when upgrading but not when reloading in case the binary on disk changed in between. The latter is a weirdest-case scenario (since you change the binary when you want to upgrade something, which won't result in a 'reload' call), though possible... You decision makes sense and is the safest. Thanks for your lights on that. > > > 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. > ... if you had changes between the binary on disk and the one being run. Which is highly unlikely to happen as calling 'reload' on the current process would mean applying the configuration made for the new binary to the old running one (which needs to be replaced ASAP since it can't resist to a server restart...). But yeah, in that weird case, you'll watch the logs. > > > > 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. > Thanks. Your input has been much appreciated, as always... --- *B. R.*
_______________________________________________ nginx mailing list [email protected] http://mailman.nginx.org/mailman/listinfo/nginx
