http://bugzilla.mindrot.org/show_bug.cgi?id=839
dtucker@zip.com.au changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #600 is|0 |1
obsolete| |
------- Additional Comments From dtucker@zip.com.au 2004-05-21 13:08 -------
Created an attachment (id=639)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=639&action=view)
Signal PAM "thread" if SIGCHLD is caused by the privsep slave exitting
Colin Watson pointed out that this may correspond to a Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248125
It appears that what is happening is that the client exits, breaking the TCP
connection. When that happens, the privsep slave exits too, which causes a
SIGCHLD to be delivered to the monitor. The monitor then attempts to waitpid()
on the PAM "thread" which is still alive and blissfully unaware of a problem
(because nobody told it to die). That waitpid hangs the monitor's cleanup.
The attached patch tests adds a test for this case to the signal handler to
shoot the PAM thread itself if it has to. It the same as the one I sent to
the Debian bug except it resets SIGCHLD to prevent reentering the signal
handler when the second process exits.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
dtucker@zip.com.au changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #600 is|0 |1
obsolete| |
------- Additional Comments From dtucker@zip.com.au 2004-05-21 13:08 -------
Created an attachment (id=639)
--> (http://bugzilla.mindrot.org/attachment.cgi?id=639&action=view)
Signal PAM "thread" if SIGCHLD is caused by the privsep slave exitting
Colin Watson pointed out that this may correspond to a Debian bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=248125
It appears that what is happening is that the client exits, breaking the TCP
connection. When that happens, the privsep slave exits too, which causes a
SIGCHLD to be delivered to the monitor. The monitor then attempts to waitpid()
on the PAM "thread" which is still alive and blissfully unaware of a problem
(because nobody told it to die). That waitpid hangs the monitor's cleanup.
The attached patch tests adds a test for this case to the signal handler to
shoot the PAM thread itself if it has to. It the same as the one I sent to
the Debian bug except it resets SIGCHLD to prevent reentering the signal
handler when the second process exits.
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.