Bug#242400: artsd hangs around after logout

[rjs@cs.hut.fi (Riku Saikkonen)]

Hi,

I can confirm part of this bug: the artsd process (started by running
some KDE application) stays alive even after I kill X and logout. I
have seen this for years (ever since I started using KDE
applications), and also currently on an etch system.

I cannot confirm the 3D graphics part of this bug, but I don't think
that is important - I think it is a bug that artsd does not shut down
properly after I log out, and a possible 3D graphics problem is just a
side effect. Having to kill such processes manually is quite
annoying...

I use KDE applications (such as konqueror) with fvwm as my window
manager (i.e., not a KDE desktop as such), but I can reproduce the bug
even without a window mananger. The following steps can be used to
reproduce this bug using a (hopefully) minimal number of external
components:

1. Log in on a text console as some user (I tried this using a user
   with an empty home directory, so any user configuration should not
   be the cause).

2. Start X without a window manager (i.e., run "X &").

3. Set your display to be able to start programs in the new X display:
   "export DISPLAY=:0"

4. Run "kdialog --yesno foo &" (or any other KDE application, this is
   the simplest one I could think of).

5. Observe that the following processes are created (7 daemon
   processes just to display a simple dialog box...):

guest    15276  2.4  1.2  26944 13468 pts/0    S    09:58   0:00 kdialog --yesno foo
guest    15278  0.1  0.6  25684  7012 ?        Ss   09:58   0:00 kdeinit Running...        
guest    15282  0.1  0.6  25608  6804 ?        S    09:58   0:00 dcopserver [kdeinit] --nosid --suicide
guest    15284  0.1  0.8  27152  8460 ?        S    09:58   0:00 klauncher [kdeinit]       
guest    15286  1.2  0.9  28064 10272 ?        S    09:58   0:00 kded [kdeinit]            
guest    15289  0.0  0.1   2692  1368 ?        S    09:58   0:00 /usr/lib/gamin/gam_server
guest    15331  1.6  1.2  34944 13364 ?        S    09:58   0:00 knotify [kdeinit]         
guest    15334  2.0  0.6  11800  6240 ?        S    09:58   0:00 /usr/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -l 3 -f
guest    15336  4.3  1.1  23328 12148 ?        S    09:58   0:00 artsmessage -i Sound server informational message:??Error while initializing the sound driver:?

   (I got the last artsmessage process because this empty user does
   not have the permissions set up to access the audio device; but
   this is irrelevant. The kdialog process has terminal pts/0 instead
   of tty1 because I ran this inside "script" to capture the output.)

6. Go to the X display, and close the dialog box by pressing the Yes
   button. (I also Oked the artsmessage window containing a warning
   about switching to a null sound device.)

7. Wait a minute or two, and observe that the other daemon processes
   shut down but artsd does not:

guest    15334  0.0  0.6  11800  6264 ?        S    09:58   0:00 /usr/bin/artsd -F 10 -S 4096 -s 60 -m artsmessage -l 3 -f

8. Then you can kill X and log out, and the artsd process still
   remains.

I reproduced the bug on a Debian etch system, with artsd from package
libarts1c2a version 1.5.5-1. I have not installed the (Recommended)
libarts1-akode package. (I have also seen leftover artsd processes on
sarge and I think even before that.)

The other six KDE-related daemon processes did know to shut themselves
down after the kdialog had closed, so perhaps the approach they use
(whatever it is) could be extended to artsd as well? Or perhaps
whatever starts the artsd process (one of the other daemons?) should
be responsible for cleaning it up?

-- 
-=- Rjs -=- rjs@cs.hut.fi, Riku.Saikkonen@hut.fi