[nginx] unnormal pid file

[洪志道]

Thank you for advice.
Yep, we should improve scripts.

Another tiny style.

diff -r 4d874b4d82ed src/core/ngx_cycle.c
--- a/src/core/ngx_cycle.c Thu Mar 16 20:38:31 2017 +0300
+++ b/src/core/ngx_cycle.c Sun Mar 19 00:59:36 2017 -0400
@@ -1046,7 +1046,6 @@
     }

     return ngx_os_signal_process(cycle, sig, pid);
-
 }

2017-03-19 5:22 GMT+08:00 Maxim Dounin <mdounin at mdounin.ru>:

> Hello!
>
> On Sat, Mar 18, 2017 at 03:43:36PM +0800, 洪志道 wrote:
>
> > Hi.
> >
> > It's easy to reproduce such problem that
> > the master/worker process are running without the pid file.
> >
> > Step by step:
> >
> > 1. Start master process.
> >     > ./objs/nginx
> >     nginx.pid successfully create with content (23234)
> >
> > 2. Create an active connection, purpose for prevent previous master exit.
> >    > telnet 127.1 80
> >
> > 3. Quit the previous master, and it still alive for a while.
> >    > kill -QUIT 23234
> >
> > 4. Start new master process 23361, and the content of nginx.pid is
> changed
> > to 23361
> >    > ./objs/nginx
> >    It successfully start because of the listening port is closed by the
> > step 3.
> >
> > 5. Wait for a while, and the nginx.pid is deleted while the old master
> > process (23234) completely quit.
> >
> > Now the master process (23361) is running without nginx.pid.
> >
> > So, there are two key points:
> > 1. Master start, I think there is not problem.
> > 2. Master Exit, is it better to add the pid check with the pid file?
> >
> > Anyway, I think we should guarantee the pid file associates with the
> > running process.
>
> By starting an additional nginx instance before the previous nginx
> has been exited you are looking for trouble anyway.  Starting
> additional instance can easily succeed even without using SIGQUIT
> to close listening sockets.  For example, nginx will happily start
> if you've changed listening socket to a different one, or use
> 'listen .. reuseport'.
>
> Instead, you should check if there is previous instance of nginx
> running, and don't try to start another one while it is running
> (and this is what init scripts usually do).  Any other approach is
> very likely to result in various problems.
>
> Adding bandaids into nginx to mitigate most obvious of the
> resulting problems is possible, but I don't really think it's
> something needed.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170319/cef11305/attachment-0001.html>