Bug 2767 - xterms don't die after logging out from X login screen
Summary: xterms don't die after logging out from X login screen
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: XFree86
Version: 6.0
Hardware: i386
OS: Linux
medium
medium
Target Milestone: ---
Assignee: David Lawrence
QA Contact:
URL:
Whiteboard:
: 2854 2883 3215 3359 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 1999-05-12 17:13 UTC by Raul Acevedo
Modified: 2008-05-01 15:37 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 1999-06-09 13:24:28 UTC
Embargoed:


Attachments (Terms of Use)

Description Raul Acevedo 1999-05-12 17:13:41 UTC
If I login via the X login screen (runlevel 5), start a
couple xterms, then logout, the xterms stay around.  This is
really bizarre because my understanding is that the X server
is restarted, so I don't know how they can hang around after
the X server dies, but they do.

I'm using GNOME.  This happens regardless of whether the
xterms are started automatically by the GNOME session or
not.  It does not happen with other X apps.

Comment 1 Chris Evans 1999-05-14 13:53:59 UTC
I see this too. It's annoying. Looks like X needs an update due to
other reported bugs so.... :-)

Comment 2 Jay Turner 1999-05-19 14:35:59 UTC
Confirmed in the test lab.

Comment 3 Jay Turner 1999-05-19 14:39:59 UTC
*** Bug 2883 has been marked as a duplicate of this bug. ***

After leaving the xsession all processes started within it
should be also killed. Thats not true for the bash started
with xterm. I usually have 5-6 xterms on my xsession and
after a few rounds of stop
and start the X there were some tenths of 'bash' still
running.

Of course you can always kill them, either manually or using
a script, or there must be a way to prevent that happening.
But, it should not happen by default and for a novice user
thats not a nice behaviour since after some period of
continuous
uptime the number of processes will exceed the limit.

------- Additional Comments From raul  05/18/99 17:10 -------
I believe this is a dup of bug #2767, which I entered on 5/14/99.

I don't know if this is related, but I've noticed that if you start
an xterm without the "&" (i.e. it's in the shell foreground), then
hit Ctrl-c, it won't die, but it will freeze up.  I'm almost 100%
sure that this situation should, and normally does, just kill the
xterm.

Comment 4 Jay Turner 1999-05-19 15:17:59 UTC
*** Bug 2854 has been marked as a duplicate of this bug. ***


xterm cannot process SIGINT. When it gets a SIGINT this
happens (shown from strace):

select(7, [4 6], [], NULL, NULL)        = ? ERESTARTNOHAND
(To be restarted)
--- SIGINT (Interrupt) ---
fork()                                  = 9747
wait4(9747, NULL, 0, NULL)              = 9747
--- SIGCHLD (Child exited) ---
wait4(-1,

after that it hangs and can only be killed with
SIGTERM/SIGKILL. This is unique to the RH6 xterm,
Dickey's latest version or earlier versions didn't
have that problem.

It has been observed on a Alpha too.

-Andi


------- Additional Comments From jbj  05/16/99 16:38 -------


*** Bug 2853 has been marked as a duplicate of this bug. ***


xterm cannot process SIGINT. When it gets a SIGINT this
happens (shown from strace):

select(7, [4 6], [], NULL, NULL)        = ? ERESTARTNOHAND
(To be restarted)
--- SIGINT (Interrupt) ---
fork()                                  = 9747
wait4(9747, NULL, 0, NULL)              = 9747
--- SIGCHLD (Child exited) ---
wait4(-1,

after that it hangs and can only be killed with
SIGTERM/SIGKILL. This is unique to the RH6 xterm,
Dickey's latest version or earlier versions didn't
have that problem.

It has been observed on a Alpha too.

-Andi

Comment 5 Jeff Johnson 1999-06-02 18:22:59 UTC
*** Bug 3215 has been marked as a duplicate of this bug. ***

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 6 Jeff Johnson 1999-06-09 13:15:59 UTC
*** Bug 3359 has been marked as a duplicate of this bug. ***

If I exit the X server via alt-control-backspace, the xterm
provided with RedHat 6.0 does not seem to terminate.  If I
run the 5.2 xterm binary from your XFree-3.3.3.1 it does
terminate when the X server goes away (as well as every
version of xterm I have ever used in the last 11-12 years).
This is a major annoyance.  I have temporarily worked around
the problem by using the 5.2 version.

Comment 7 Jeff Johnson 1999-06-09 13:24:59 UTC
This problem can be fixed by installing utempter-0.5-2 from
Raw Hide. An errata will be out in the next day or so.


Note You need to log in before you can comment on or make changes to this bug.