Nginx reload problem

[Maxim Dounin]

Hello!

On Sun, Aug 18, 2013 at 05:29:11PM -0400, B.R. wrote:

[...]

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

Quote from my first messages in this thread:

: What is very wrong is to assume that sending
: a HUP signal to nginx is enough for a reload.  For various
: reasons, ranging from configuration syntax errors to out of memory
: problems, configuration reload might fail.

Even if the binary on disk matches one in memory, and 
configuration syntax is ok - it's always possible that system will 
run out of memory or file descriptors (or will reach per-process 
limits), or newly configured listening sockets will conflict with some 
other services running (or previously configured sockets in case 
of Linux, which doesn't allow wildcard and non-wildcard sockets to 
coexists), or something else will happen (including cases when 
reload is not possible due to requested configuration changes, see 
original question).

Questions "why nginx can't reload configuration" appear in mailing 
lists on a regular basis.  In addition to this thread, this week 
seen at least once in nginx-ru@, see [1].  Correct answer is 
usually the same - "Try looking into error log".  

[1] http://mailman.nginx.org/pipermail/nginx-ru/2013-August/051677.html

-- 
Maxim Dounin
http://nginx.org/en/donation.html