Bug 243135
Summary: | Gnome desktop panel and applets hang | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Bill C. Riemers <briemers> |
Component: | esound | Assignee: | Bastien Nocera <bnocera> |
Status: | CLOSED DUPLICATE | QA Contact: | |
Severity: | high | Docs Contact: | |
Priority: | medium | ||
Version: | 7 | CC: | nick, rstrode |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-06-10 14:47:00 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Bill C. Riemers
2007-06-07 14:16:25 UTC
Hmmm. It turns out forcibly killing the stalled background preferences window does not always stall the panel. For the first time, I force quit the background preference window and the panel continued to work normally. Furthermore, I was able to reopen background preferences and have it work once after that. I suspect this problem is a thread deadlock, because have not had this problem occur on any of my single processor machines. (The dell490 has two dual core processors.) Bill I have noticed a similar problem ... several apps hang (evolution is one), the panel locks up ... After running strace on some of the hanging apps, I find that they all seems to hang in a read of /tmp/.esd/socket. Sending a HUP to the esd frees them up (for a while). It was working great for about a day and a half. Then I made the mistake of enabling system sounds. The next time I logged in, gnome hanged on login, and every time afterwards. For the sake of stability, I decided to use KDE until this problem is resolved. Here's a typical strace .... access("/tmp/.esd/socket", R_OK|W_OK) = 0 socket(PF_FILE, SOCK_STREAM, 0) = 16 fcntl64(16, F_SETFD, FD_CLOEXEC) = 0 setsockopt(16, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0 connect(16, {sa_family=AF_FILE, path="/tmp/.esd/socket"}, 18) = 0 rt_sigaction(SIGPIPE, {0x41957e0, [PIPE], SA_RESTART}, {SIG_IGN}, 8) = 0 open("/home/nick/.esd_auth", O_RDONLY) = 17 read(17, "%\255\322\345\217\253\34+\266\303\"@\0306\246\220", 16) = 16 write(16, "%\255\322\345\217\253\34+\266\303\"@\0306\246\220", 16) = 16 write(16, "NDNE", 4) = 4 read(16, A work-around for this problem appears to be: 1. kill the esd 2. Run gnome-sound-properties and on the "Sounds" tab disable esd. At this point, everything seems to work as expected (sans sound!) Nick is right. The problem is definitely esd. I've reproduced the same problem on two other machines by enabling esd. Bastien, I think I saw similar esd bug fly by that was recently fixed? Duplicate of bug #238680? Workaround.... edit /etc/esd.conf change default_options= to default_options=-nobeeps -unix -as 2 Yes, now that we determined esd is the cause, this is a duplicate bug. I do not see how disabling beeps is going to help. Any esd sound can cause the freeze. *** This bug has been marked as a duplicate of 238680 *** |