[nginx] unnormal pid file
hongzhidao at gmail.com
Sun Mar 19 03:45:48 UTC 2017
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>:
> 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
> > 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
> nginx-devel mailing list
> nginx-devel at nginx.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the nginx-devel