Bug 2767 - xterms don't die after logging out from X login screen
xterms don't die after logging out from X login screen
Status: CLOSED CURRENTRELEASE
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
6.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: David Lawrence
:
: 2854 2883 3215 3359 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 1999-05-12 13:13 EDT by Raul Acevedo
Modified: 2008-05-01 11:37 EDT (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 1999-06-09 09:24:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Raul Acevedo 1999-05-12 13:13:41 EDT
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 09:53:59 EDT
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 10:35:59 EDT
Confirmed in the test lab.
Comment 3 Jay Turner 1999-05-19 10:39:59 EDT
*** 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@cantara.com  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 11:17:59 EDT
*** 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@redhat.com  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 14:22:59 EDT
*** 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 09:15:59 EDT
*** 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 09:24:59 EDT
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.