Is there any chance this patch will be included in a future release?

Thanks.

2016-02-18 10:52 GMT-05:00 Philippe Anctil philippe.anctil@gmail.com:

I am proposing the following patch.

Signal blocking effectively prevents signals from being processed by the child before it has the time to change disposition.

I re-ran my test script and the result is now correct. Signals sent to child are no longer caught by parent.

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.

Additional notes from http://man7.org/linux/man-pages/man7/signal.7.html:

• A child created via fork(2) inherits a copy of its parent's signal mask;

the signal mask is preserved across execve(2).

• A child created via fork(2) initially has an empty pending signal set;

the pending signal set is preserved across an execve(2).

All this is on RHEL5.11.

Regards,

2016-02-17 18:36 GMT-05:00 Philippe Anctil philippe.anctil@gmail.com:

...

Hi,

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.

By the way, why is SIG_CHLD set to null_handler in create_client? The default disposition for this signal is SIG_IGN.

Regards,

2016-02-16 11:45 GMT-05:00 Philippe Anctil philippe.anctil@gmail.com:

...

Hi,

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.

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.

Processes before sigterm:

UID PID PPID C STIME TTY STAT TIME CMD user 1423 1 0 10:32 ? Ss 0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf user 1921 1423 0 10:37 ? S 0:00 _ /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf

selected pid 1423

Processes after:

UID PID PPID C STIME TTY STAT TIME CMD user 1921 1 0 10:37 ? S 0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf

Here I sent the signal to the child. The parent shut down and the child completed normally.

Processes before:

UID PID PPID C STIME TTY STAT TIME CMD user 1276 1 0 10:31 ? Ss 0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf user 1309 1276 0 10:31 ? S 0:00 _ /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf

selected pid 1309

Processes after:

UID PID PPID C STIME TTY STAT TIME CMD user 1309 1 0 10:31 ? S 0:00 /usr/local/stunnel/bin/stunnel.bin /usr/local/stunnel/etc/server.conf

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.

Best regards,

-- Philippe Anctil

-- Philippe Anctil

-- Philippe Anctil

Hi,

Thanks for your reply. I won't argue forever on this minor aspect. In closing I simply want to say I find it very unusual to send a signal to a child and see it processed by the parent. Are there other servers out there behaving this way?

Regards,

2016-03-14 13:16 GMT-04:00 Michal Trojnara Michal.Trojnara@stunnel.org:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 14.03.2016 16:52, Philippe Anctil wrote:

...

Is there any chance this patch will be included in a future release?

No, there is not. Stunnel works as it was designed to work. I can see no reason to change the design.

Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2

iQIcBAEBCAAGBQJW5vHbAAoJEC78f/DUFuAUC98P/iTzjb5lwFFu1OwjRueXMj7M DrpvgvRSaIR5a0y6Ver/jfE6E0MYkKhaMREysjStwTP3prcrjujslh8iSt5Mo1df wtpIDhCT1EVrMRXNm01xfhQbKh+//HW4mfBGNENw6JSt/+sAueibWw2NwZ2AF8iF L8Xlf8qf7CwnmxL2dh893d3aeqBqMDeEe7b3foD3bgM2aDUxpIXsOaIQdTG4WKoY nWkVnbeOB9oyNqucGqIU53ceYTrBUl+aX71tR3VEkbZvChAG4dxJuZqea2gp7OTc 9TdjYR8d2KCnk+EbP/RBDUg8+jL2hJUIF2CnDAWZRgP7aIqk24jLsLjSha9Oj7cS gRFUU+4RlhzeRjnqiiSjcAukD3El6jfIk3xi//ZfU/5ItQjmObaPaLKkL2zm5iuR k3Md07bxvcEzquagVhxxdVKFU2f3D2+0esyxUOYsulK2geHKkg5uqZYLd6tZjFgI F9MkNlE4rRy9SbKifDIbLjUFAePh0yq5R1279U+y/250gbZsB4jDfZnZCFlOVUq0 UwOh/XUr+jdxyXvcLuK2zk3ne82cXDDCdG7JfWS+XV/Tl0cY3J/FiujR8tAj5sSz FsH1G+3Cx4bWO1xqEDb5cJYhcBi9JAept1OT5GF27cVskup1FP7NU6GmHkj2skfy YxyS5+QkPyeC4qmSvdBN =3PMO -----END PGP SIGNATURE----- _______________________________________________ stunnel-users mailing list stunnel-users@stunnel.org https://www.stunnel.org/cgi-bin/mailman/listinfo/stunnel-users