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 -=- [EMAIL PROTECTED], [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]