Nginx reload problem

[B.R.]

Hello,

On Sun, Aug 18, 2013 at 3:14 PM, Maxim Dounin <mdounin at mdounin.ru> 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.*
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20130818/e70d6e63/attachment-0001.html>