Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: Same like in FC4. Don't know why, but the esd sound daemon seems to block some part of the gnome desktop/ panel, and/ or metactity. E.g. you can mouse-click on the "Application Menu" on the upper panel, but nothing happens. You can mouse-click on the firefox icon, nothing happens. # ipcs -s ------ Semaphore Arrays -------- key semid owner perms nsems 0x2630b302 196608 thomas 600 1 Semaphore Array semid=196608 uid=500 gid=500 cuid=500 cgid=500 mode=0600, access_perms=0600 nsems = 1 otime = Mon Apr 24 10:26:06 2006 ctime = Mon Apr 24 10:26:06 2006 semnum value ncount zcount pid 0 1 0 1 2760 # ps -ef | grep 2760 user 2760 1 0 Apr23 ? 00:00:00 /usr/bin/esd -terminate -nobeeps -as 2 -spawnfd 18 # strace -p 2760 Process 2760 attached - interrupt to quit semget(640725762, 1, IPC_CREAT|0600) = 196608 semop(196608, 0xaf8b3b0e, 2 When I remove the semaphore, esd will create a new one, and when I remove this too, all the processes come to live, which are blocking before (firefox, the Application menu ..). # strace -p 2760 (Removing the semaphore) Process 2760 attached - interrupt to quit semget(640725762, 1, IPC_CREAT|0600) = 196608 semop(196608, 0xaf8b3b0e, 2) = -1 EIDRM (Identifier removed) semget(640725762, 1, IPC_CREAT|0600) = 229376 semop(229376, 0xaf8b3b0e, 2) = 0 shmget(403027995, 384, IPC_CREAT|0600) = 425984 shmat(425984, 0, 0) = 0xa7f9f000 mlock(0xa7f9f000, 384) = 0 shmctl(425984, IPC_64|IPC_STAT, 0xaf8b3a58) = 0 open("/dev/snd/controlC0", O_RDONLY) = 34 close(34) = 0 open("/dev/snd/controlC0", O_RDWR) = 34 ioctl(34, USBDEVFS_CONTROL, 0xaf8b37c4) = 0 ioctl(34, 0x40045532, 0xaf8b37e4) = 0 open("/dev/snd/pcmC0D0p", O_RDWR|O_NONBLOCK) = -1 EBUSY (Device or resource busy) close(34) = 0 write(2, "ALSA lib pcm_dmix.c:865:(snd_pcm"..., 44) = 44 write(2, "unable to open slave", 20) = 20 write(2, "\n", 1) = 1 shmdt(0) = -1 EINVAL (Invalid argument) shmdt(0xa7f9f000) = 0 shmctl(425984, IPC_64|IPC_STAT, 0xaf8b3a5c) = 0 nanosleep({0, 11000000}, NULL) = 0 select(34, [4 5 12 14 16 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33], NULL, NULL, {0, 0}) = 1 (in [1 2], left {0, 0}) accept(4, 0xaf8b4268, [16]) = -1 EAGAIN (Resource temporarily unavailable) select(34, [33], NULL, NULL, {0, 0}) = 0 (Timeout) select(33, [32], NULL, NULL, {0, 0}) = 0 (Timeout) select(32, [31], NULL, NULL, {0, 0}) = 0 (Timeout) select(31, [30], NULL, NULL, {0, 0}) = 0 (Timeout) select(30, [29], NULL, NULL, {0, 0}) = 0 (Timeout) select(29, [28], NULL, NULL, {0, 0}) = 0 (Timeout) select(28, [27], NULL, NULL, {0, 0}) = 0 (Timeout) select(27, [26], NULL, NULL, {0, 0}) = 0 (Timeout) select(26, [25], NULL, NULL, {0, 0}) = 0 (Timeout) Seems that is problem with the ALSA sound. However the desktop/ gnome should no block for a problem like this! Version-Release number of selected component (if applicable): esound-0.2.36-2.2.1 How reproducible: Randomly, when another sound tool is playing. Steps to Reproduce: 1. 2. 3. Actual results: part of the desktop/ panel blocking. Expected results: No blocking if esd has a problem. Additional info:
Killing esd also brings the application and desktop back to live.
No work here?
I see the same behavior upon login on a fresh boot on my laptop. I can usually trigger it by logging in very quickly once gdm is up. I haven't tried messing with this yet, but I have ESD and "play system sounds" turned on in sound preferences, if it makes a difference. My normal course of action is usually to switch to a text terminal, kill off the first/youngest esd process (there are always two), and login proceeds normally, albeit without sound for that session.
Is this a problem in rawhide, too ?
I don't use rawhide. Very late reaction on this problem.
Looks like esd is starting up more than once, or after session closed (logout), a new esd is starting up - and blocking the other one.
*** This bug has been marked as a duplicate of 187959 ***