How to find and clear zombie processes w/o rebooting?
 

On 25Jun2008 19:08, Daniel B. Thurman <dant@cdkkt.com> wrote:
> Looks like the parent is related to gdm-binary?
> Strange about my comment previously - hit 'reset' :D
> Wonder what is going on with Xsession and why it died.
>
> This is what I found:
> ===================
> root 3704 0.0 0.1 18416 2096 ? Ss Jun24 0:00 /usr/sbin/gdm-binary -nodaemon
> root 3797 0.0 0.0 17896 2064 ? S Jun24 0:00 \_ /usr/sbin/gdm-binary -nodaemon
> root 3801 2.4 2.2 63512 47528 tty7 Ss+ Jun24 40:15 \_ /usr/bin/X :0 -br -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7
> dant 3854 0.0 0.1 33768 4104 ? Ssl Jun24 0:01 \_ /usr/bin/gnome-session
> dant 3902 0.0 0.0 0 0 ? Z Jun24 0:00 \_ [Xsession] <defunct>
> dant 3956 0.0 0.0 6328 252 ? Ss Jun24 0:00 \_ /usr/bin/ssh-agent /usr/bin/dbus-launch --exit-with-session /etc/X11/xinit/Xclients
[...]

Ok, this mean gnome-session forked a run of Xsession and didn't wait for
it. Xsession has exited, but whatever gnome-session really waits for
(typically the window manager) has not yet exited.

This is really common in xsession/xinitrc type shell scripts. You see
people write their sessions like this:

xterm &
xclock &
window-manager

So, that is a shell script. It kicks off a terminal, a clock and a
window manager. It waits for that last. When the window manager exits
(usually from the quit/logout menu item), the session ends, and gdm/xdm
kills the X server and starts a new server for a new login prompt.

Now.. if the terminal or clock exit, they will be zombies. The script is
may be waiting only for the window manager, expecially if the last line
goes:

exec window-manager

because the window manager will _replace_ the script, and thus be the
parent of the terminal and clock, but it will not be waiting for them.

It is normally desirable to run "tools" (the terminal, the clock,
nautilus etc) as children of a throw away subshell, thus:

( xterm &
xclock &
)
exec window manager

That way the tools are forked off from a subshell, the subshell exits,
and the children get inherited by init (_not_ the top shell!) whose
purpose in life is to catch such children and reap them, to prevent them
becoming zombies.

So:
- it is really a problem in gnome-session
- it isn't important, and is not related to your resource problems

Cheers,
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

In article <CF3rw3.n0x@eskimo.com> pirih@eskimo.com (Chris Pirih) writes:
| Wotsa zerk?

It's a portable hemispherical perforated spooge flange.
- Chuck Rogers, car377@torreys.att.com

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

How to find and clear zombie processes w/o rebooting?
 

Title: Re: How to find and clear zombie processes w/o rebooting?




Cameron Simpson wrote:






On 25Jun2008 19:08, Daniel B. Thurman
<dant@cdkkt.com> wrote:


> Looks like the parent is related to gdm-binary?


> Strange about my comment previously - hit 'reset'
:D


> Wonder what is going on with Xsession and why it
died.


>


> This is what I found:


> ===================


> root***** 3704* 0.0* 0.1* 18416* 2096 ?*******
Ss** Jun24** 0:00 /usr/sbin/gdm-binary -nodaemon


> root***** 3797* 0.0* 0.0* 17896* 2064 ?*******
S*** Jun24** 0:00* \_ /usr/sbin/gdm-binary -nodaemon


> root***** 3801* 2.4* 2.2* 63512 47528 tty7****
Ss+* Jun24* 40:15***** \_ /usr/bin/X :0 -br -audit 0 -auth
/var/gdm/:0.Xauth -nolisten tcp vt7


> dant***** 3854* 0.0* 0.1* 33768* 4104 ?*******
Ssl* Jun24** 0:01***** \_ /usr/bin/gnome-session


> dant***** 3902* 0.0* 0.0***** 0**** 0 ?*******
Z*** Jun24** 0:00********* \_ [Xsession] <defunct>


> dant***** 3956* 0.0* 0.0** 6328** 252 ?*******
Ss** Jun24** 0:00********* \_ /usr/bin/ssh-agent /usr/bin/dbus-launch
--exit-with-session /etc/X11/xinit/Xclients


[...]



Ok, this mean gnome-session forked a run of
Xsession and didn't wait for


it. Xsession has exited, but whatever gnome-session
really waits for


(typically the window manager) has not yet exited.



This is really common in xsession/xinitrc type
shell scripts. You see


people write their sessions like this:



* xterm &


* xclock &


* window-manager



So, that is a shell script. It kicks off a
terminal, a clock and a


window manager. It waits for that last. When the
window manager exits


(usually from the quit/logout menu item), the session
ends, and gdm/xdm


kills the X server and starts a new server for a new
login prompt.



Now.. if the terminal or clock exit, they will be
zombies. The script is


may be waiting only for the window manager, expecially
if the last line


goes:



* exec window-manager



because the window manager will _replace_ the
script, and thus be the


parent of the terminal and clock, but it will not be
waiting for them.



It is normally desirable to run "tools" (the
terminal, the clock,


nautilus etc) as children of a throw away subshell,
thus:



* ( xterm &


*** xclock &


* )


* exec window manager



That way the tools are forked off from a subshell,
the subshell exits,


and the children get inherited by init (_not_ the top
shell!) whose


purpose in life is to catch such children and reap
them, to prevent them


becoming zombies.



So:


* - it is really a problem in gnome-session


* - it isn't important, and is not related to your
resource problems





Well! Thanks for the explanation!

I guess I will just reboot - problem solved!



Thanks alot!

Dan





--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

How to find and clear zombie processes w/o rebooting?
 

On Thu, 2008-06-26 at 12:34 +1000, Cameron Simpson wrote:
> xterm &
> xclock &
> window-manager
>
> So, that is a shell script. It kicks off a terminal, a clock and a
> window manager. It waits for that last. When the window manager exits
> (usually from the quit/logout menu item), the session ends, and
> gdm/xdm
> kills the X server and starts a new server for a new login prompt.
>
> Now.. if the terminal or clock exit, they will be zombies.

In fact the Shell waits for forked processes, so they won't be zombies.

poc

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

How to find and clear zombie processes w/o rebooting?
 

On 25Jun2008 20:49, Daniel B. Thurman <dant@cdkkt.com> wrote:
> Well! Thanks for the explanation!

No worries.

> I guess I will just reboot - problem solved!

No, just deferred. Presumably it will happen again.

Next time it happens, try doing a "ps elf" and examine the RSS (resident)
and VSZ (virtual size) columns. They may point the way to an unreasonably
large process. You can also tell "top" to sort its display by process
memory size, and to show "idle" processes (press "i"), which it normally
doesn't bother to display.

Cheers,
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Why is it whatever we don't understand is called a 'thing'? - "Bones" McCoy

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list

How to find and clear zombie processes w/o rebooting?
 

On 25Jun2008 23:45, Patrick O'Callaghan <pocallaghan@gmail.com> wrote:
| On Thu, 2008-06-26 at 12:34 +1000, Cameron Simpson wrote:
| > xterm &
| > xclock &
| > window-manager
| >
| > So, that is a shell script. It kicks off a terminal, a clock and a
| > window manager. It waits for that last. When the window manager exits
| > (usually from the quit/logout menu item), the session ends, and
| > gdm/xdm
| > kills the X server and starts a new server for a new login prompt.
| >
| > Now.. if the terminal or clock exit, they will be zombies.
|
| In fact the Shell waits for forked processes, so they won't be zombies.

Indeed. However if it execs the window manager, the window manager usually
won't. But point taken.
--
Cameron Simpson <cs@zip.com.au> DoD#743
http://www.cskk.ezoshosting.com/cs/

Anarchy is not lack of order. Anarchy is lack of ORDERS.

--
fedora-list mailing list
fedora-list@redhat.com
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list