Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.

Bug 3215

Summary: signal-misdelivery in X?
Product: [Retired] Red Hat Linux Reporter: aaron
Component: XFree86Assignee: David Lawrence <dkl>
Status: CLOSED DUPLICATE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0CC: zab
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 1999-06-02 18:22:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description aaron 1999-06-02 17:31:24 UTC
I'm not sure whether or not the problem is a kernel signal
delivery one, or whether it's just the new version of Xfree
programs being flaky, but I'm finding this extremely
annoying.

If I kill an xterm with a SIGTERM, it goes comatose instead
of killing its child shell and going away.

select(8, [6 7], [], NULL, NULL)        = ? ERESTARTNOHAND
(To be restarted)
--- SIGTERM (Terminated) ---
fork()                                  = 1350
wait4(1350, NULL, 0, NULL)              = 1350
--- SIGCHLD (Child exited) ---
wait4(-1,

at which point it just sits, which of course during a logout
leads to a bunch of xterms and their child shells sitting
around in the process table, eating ptys and memory for not
reason at all.  The same fate awaits any processes run from
a user's .xsession.

if a SIGHUP is sent to the child shell, then the xterm
exits.

Repeating the same experiment on a NetBSD box leads to the
expected results, with no orphaned xterms in the process
table after a logout.

I'm running a 400Mhz K6-2, stepping 12, with kernel 2.2.5 as
shipped with RH6.0  I have tried kernels 2.2.4, 2.2.9, and
2.3.4 compiled with gcc 2.7.2.3 and egcs without any
success.

This signal misdelivery also shows up on my AMD 5x86-133 at
home, also running RH6.0 with distributed 2.2.5 kernel.

Comment 1 Jeff Johnson 1999-06-02 18:22:59 UTC
*** This bug has been marked as a duplicate of 2767 ***