Description of problem: Version-Release number of selected component (if applicable): I just did a fresh install on my Dell490 of x86_64 Fedora 7. However, GNOME keeps hanging. Initially, gnome would hang in the startup sequence just after playing a startup sound. The mouse would still respond, but the panel would freeze in an incomplete render state. At that point, the only way I can even logout is to do a CTRL+ALT+BACKSPACE. I then have to manually kill processes in a console window before I try again. I thought maybe the problem was that I used the same home directory as with RHEL5. So I created a brand new user, and a brand new directory. With the brand new user, I am able to login and even do things like start firefox to report this bug. But eventually, the panel always seems to freeze. At that point, the only way I can even logout is to do a CTRL+ALT+BACKSPACE. I then have to manually kill processes in a console window before I try again. Otherwise, when I restart the panel won't even be displayed. Also, if I try to change the background, the gnome applet for background applet freezes as soon as I try changing FullScreen to Tiled. The applet stops updating all together with the pop-up dialog still open. If I cover the window and then uncover it, it never repaints itself. I suspect these two problems are related, because if I do a force kill on the stalled applet, the panel will allow me just one more action before it freezes. How reproducible: Always, with enough time. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
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 ***