<div dir="ltr"><div>Is there any chance this patch will be included in a future release? </div><div><br></div><div>Thanks.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2016-02-18 10:52 GMT-05:00 Philippe Anctil <span dir="ltr"><<a href="mailto:philippe.anctil@gmail.com" target="_blank">philippe.anctil@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I am proposing the following patch. <div><br><div>Signal blocking effectively prevents signals from being processed by the child before it has the time to change disposition. <div><br></div><div>I re-ran my test script and the result is now correct. Signals sent to child are no longer caught by parent.<br></div><div><br></div><div>With a small program I also tested what happens with pended signals if their disposition is changed before they're delivered. They're simply delivered according to the new disposition. Example. If a SIGTERM is sent to the child right after the fork, the signal will be pended. The child will then change the signal disposition to SIG_DFL (terminate). When the child unblocks the signals, SIGTERM is delivered to the child and the child terminates. </div><div><br></div><div><div>Additional notes from <a href="http://man7.org/linux/man-pages/man7/signal.7.html" target="_blank">http://man7.org/linux/man-pages/man7/signal.7.html</a>:</div><div><div>- A child created via fork(2) inherits a copy of its parent's signal mask; the signal mask is preserved across execve(2).</div><div>- A child created via fork(2) initially has an empty pending signal set; the pending signal set is preserved across an execve(2).</div></div></div><div><br></div><div>All this is on RHEL5.11.</div><div><br></div><div>Regards,</div><div><br></div><div><br></div></div></div></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">2016-02-17 18:36 GMT-05:00 Philippe Anctil <span dir="ltr"><<a href="mailto:philippe.anctil@gmail.com" target="_blank">philippe.anctil@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>I have looked further into this issue. Part of the solution would be to reset signal disposition to SIG_DFL, either in the child after the fork, or around the call to create_client in accept connection for the child to inherit appropriate disposition from the start. Temporarily blocking signals could help. I have to verify exactly how it behaves. </div><div><br></div><div><div>By the way, why is SIG_CHLD set to null_handler in create_client? The default disposition for this signal is SIG_IGN.</div></div><div><br></div><div>Regards,</div><div><br></div></div><div class="gmail_extra"><div><div><br><div class="gmail_quote">2016-02-16 11:45 GMT-05:00 Philippe Anctil <span dir="ltr"><<a href="mailto:philippe.anctil@gmail.com" target="_blank">philippe.anctil@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi,<div><br></div><div>In fork mode, sending a sigterm signal to a child is caught by the parent. I suspect it has something to do with signal_pipe being shared by the child and parent after the fork.</div><div><br></div><div>Here I sent a signal to the parent while a child process was also running. The parent shut down as expected. After sending sigterm, the child remains.<br></div><div><br></div><div>Processes before sigterm: </div><div><br></div><div><div>UID        PID  PPID  C STIME TTY      STAT   TIME CMD</div><div>user      1423     1  0 10:32 ?        Ss     0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf</div><div>user      1921  1423  0 10:37 ?        S      0:00  \_ /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf</div><div><br></div><div>selected pid 1423</div><div><br></div><div>Processes after:</div><div><br></div><div>UID        PID  PPID  C STIME TTY      STAT   TIME CMD</div><div>user      1921     1  0 10:37 ?        S      0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf</div></div><div><br></div><div>Here I sent the signal to the child. The parent shut down and the child completed normally.</div><div><br></div><div>Processes before:</div><div><br></div><div><div><div>UID        PID  PPID  C STIME TTY      STAT   TIME CMD</div><div>user      1276     1  0 10:31 ?        Ss     0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf</div><div>user      1309  1276  0 10:31 ?        S      0:00  \_ /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf</div><div><br></div><div>selected pid 1309</div><div><br></div><div>Processes after:</div><div><br></div><div>UID        PID  PPID  C STIME TTY      STAT   TIME CMD</div><div>user      1309     1  0 10:31 ?        S      0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf</div></div><div><br></div><div>I know I should be trying threads. I will eventually. I can only switch once I validate it can sustain our level of traffic. Fork has done that flawlessly for many years now. <br></div><div><br></div><div>Best regards,</div><span><font color="#888888"><div><br></div><div><div><br></div>-- <br><div><div dir="ltr">Philippe Anctil</div></div>
</div></font></span></div></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span><font color="#888888">-- <br><div><div dir="ltr">Philippe Anctil</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div></div></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr">Philippe Anctil</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr">Philippe Anctil</div></div>
</div>