Bug 115337

Could you update ALSA packages on
ftp.suse.com/pub/projects/alsa/SL10.0b4-fix/alsa/*.rpm, and see whether this
still occurs?

I updated and the processes still appear.

You killed once them and restart, right?  Also, make sure that it's
alsa-1.0.9-21.i586.rpm (not 18).  The server might be not synchronized yet.

Then, please check "fuser /dev/snd/pcmC0D0p" whether the remaining processes
open this device.  If the artsd still opens the device, it's either a forked
dmix server (which is no problem), or a bug in artsd which doesn't close the PCM.

I installed the rpm, killed all the artsd processes, changed the runlevel to 3
and then back to 5. Then logged in and out with 2 different users-> I had 2
artsd processes running. The version reported by rpm is alsa-1.0.9-21.


The fuser command shows no files at all, even while I am logged in. Maybe this
can help you:

# lsof | grep gast
resmgrd   4424       root   77w      REG        3,6       0    6607842
/var/run/resmgr/classes/desktop/gast (deleted)
resmgrd   4424       root   78w      REG        3,6       0    9936445
/var/run/resmgr/classes/dvb/gast (deleted)
resmgrd   4424       root   79w      REG        3,6       0   11222331
/var/run/resmgr/classes/v4l/gast (deleted)
resmgrd   4424       root   80w      REG        3,6       0   13806086
/var/run/resmgr/classes/sound/gast (deleted)
resmgrd   4424       root   81w      REG        3,6       0   15826818
/var/run/resmgr/classes/video/gast (deleted)
resmgrd   4424       root   82w      REG        3,6       0     289327
/var/run/resmgr/classes/input/gast (deleted)
resmgrd   4424       root   83w      REG        3,6       0    2867970
/var/run/resmgr/classes/cdrom/gast (deleted)
resmgrd   4424       root   84w      REG        3,6       0    5262364
/var/run/resmgr/classes/floppy/gast (deleted)
resmgrd   4424       root   85w      REG        3,6       0    6607843
/var/run/resmgr/classes/usb/gast (deleted)
resmgrd   4424       root   86w      REG        3,6       0    9936446
/var/run/resmgr/classes/camera/gast (deleted)
resmgrd   4424       root   87w      REG        3,6       0   11222332
/var/run/resmgr/classes/scanner/gast (deleted)
resmgrd   4424       root   88w      REG        3,6       0   13806087
/var/run/resmgr/classes/pda/gast (deleted)
resmgrd   4424       root   89w      REG        3,6       0    6607844
/var/run/resmgr/classes/desktop/gast (deleted)
resmgrd   4424       root   90w      REG        3,6       0    9936447
/var/run/resmgr/classes/dvb/gast (deleted)
resmgrd   4424       root   91w      REG        3,6       0   11222334
/var/run/resmgr/classes/v4l/gast (deleted)
resmgrd   4424       root   92w      REG        3,6       0   13806089
/var/run/resmgr/classes/sound/gast (deleted)
resmgrd   4424       root   93w      REG        3,6       0   15826819
/var/run/resmgr/classes/video/gast (deleted)
resmgrd   4424       root   94w      REG        3,6       0     289326
/var/run/resmgr/classes/input/gast (deleted)
resmgrd   4424       root   95w      REG        3,6       0    2867968
/var/run/resmgr/classes/cdrom/gast (deleted)
resmgrd   4424       root   96w      REG        3,6       0    5262366
/var/run/resmgr/classes/floppy/gast (deleted)
resmgrd   4424       root   97w      REG        3,6       0    6607845
/var/run/resmgr/classes/usb/gast (deleted)
resmgrd   4424       root   98w      REG        3,6       0    9722539
/var/run/resmgr/classes/camera/gast (deleted)
resmgrd   4424       root   99w      REG        3,6       0   11222335
/var/run/resmgr/classes/scanner/gast (deleted)
resmgrd   4424       root  100w      REG        3,6       0   13806092
/var/run/resmgr/classes/pda/gast (deleted)

This was when user "gast" was already logged out, with a leftover artsd
(belonging to gast!) still running. I find this somewhat strange: doesn't this
mean that artsd doesn't have any open files? Otherwise they should have been found.

It looks so.

Anyway, if your sound chip is on-board chip and not VIA82xx, please add the
following to your ~/.asoundrc

pcm.!default "plughw"

then login again after killing remaining artsd.  This will avoid the use of dmix
plugin.  If artsd still remains after login, it must be a bug of artsd itself.

The pcm.!default stuff worked! No more artsd after logout. Just in case it helps
you, lspci says the following about my soundcard:

00:00.0 Host bridge: Intel Corporation 82855PM Processor to I/O Controller (rev 03)
00:01.0 PCI bridge: Intel Corporation 82855PM Processor to AGP Controller (rev 03)
[...]
00:1f.5 Multimedia audio controller: Intel Corporation 82801DB/DBL/DBM
(ICH4/ICH4-L/ICH4-M) AC'97 Audio Controller (rev 03)

I'll be offline for the next couple of hours, so don't expect quick replies.

Well, then it's a remaining dmix server by unkown reason.  They should be dead
automatically after a certain time (usually 50ms).  A possible reason is a
semaphore deadlock.

Please check "ipcs" and clean up unused shm and semaphores via "ipcrm" once (or
just reboot to get a fresh status).
Then revert ~/.asoundrc and see whether still the process remains there.

After shutting down kdm, there were no more semaphores and no shm. But there was
still an artsd running. Btw, this thing is starting to really annoy me since I
have the impression that it is not always reproducable.

I also did an strace of this artsd process which shows that it is receiving
SIGALARM all the time. I'll attach the log.

Created attachment 48984 [details]
strace of a leftover artsd process

Note that the resource server seems to be killed. The standard "trace" for the
resource server is:

poll([{fd=6, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0
semop(491520, 0xbfffc750, 2)            = 0
shmctl(5734406, IPC_64|IPC_STAT, 0xbfffc760) = 0
semop(491520, 0xbfffc730, 1)            = 0
poll([{fd=6, events=POLLIN|POLLERR|POLLHUP}], 1, 500) = 0

I want to confirm that I expirience this problem too. What is double anyoing me is that that artsd probably keeps a file handle open on the /home directory of the user. Since my /home directory is mounted over nfs on a server, the directory is not unmounted when I drive down the desktop client computer. 
Even worse, when rebooting the client desktop after such an unclean shutdown, the server won't let the desktop-client reconnect the /home directory. I first have to restart the nfs server on the server.

Luckily the ~/.asoundrc pcm.!default "plughw" trick works for me, so I created this file in all the home directories of all the users on the desktop.

Forgot to add above: I'm running SuSE 10.0 final.

Hello folks--

I think I got this solved! Yes, I join you in your frustrations! I upgraded from 9.2 to 10.0 two weeks ago and after experiencing this hang up MOST of the time but not all the time, it boiled down to this.

You have a script in /opt/kde3/bin called "startkde" which both starts and stops KDE. In it you will find, toward the bottom, a call to kdeinit_shutdown to stop scripts AND an additional call to terminate the artsd server with 'artsshell terminate'. Get rid of the second line (I actually commented mine out), and your troubles will be solved.

I'm thinking that between KDE say 3.3 and 3.4 the KDE folks had the kdeinit stop ALSO stop artsd and forgot to get rid of the additional kill.

Cheers! and as always, Have a lot of fun! :)