Comment from upstream: "Typically the problem when the GDM daemon becomes so unresponsive is because it has crashed. Note that GDM works like this;
1. The main GDM daemon starts. This is the process that has the pid listed in /var/run/gdm.pid. Note that most programs try to connect to this process when they want to communicate. For example gdmflexiserver looks up the daemon process Pid in this file. 2. For each display, a forked daemon (aka the slave daemon) is started. 3. The forked daemon starts the GUI program (gdmlogin/gdmgreeter). Note it can look like daemon's are still running even when the main daemon has crashed since the forked slave daemons (#2 above) may still be running. If the main daemon is crashing, has it left a core file somewhere. Look for GDM related core files in the /, /var/lib/gdm, /var/lib/log/gdm, or the GDM user's $HOME directory (if any). I suspect all of the above won't help you since it sounds like the main daemon isn't crashing. I just mention this so you can double check, since this is typically the problem for this sort of symptom. GDM uses a couple of different mechanisms to communicate between the main daemon and other processes. There is the GDM_SUP* messages that are used by various programs to query the daemon about different hings. What happens when you run this command. It tests the GDM_SUP* messages. Does it work? gdmflexiserver --command=VERSION The other kind of messages are GDM_SOP_* messages. For these messages, the forked slave process sends the main daemon a SIGUSR1 signal and then uses a fifo protocol for passing the messages. Note the function create_connections in daemon/gdm.c and note gdm_slave_send in daemon/slave.c. In your syslog, it seems like messages like GDM_SOP_LOGGED_IN (aka LOGGED_IN) is failing. So this is probably where it is breaking. I'm wondering if this is the *only* kind of message that is breaking or if just GDM_SOP messages are broken for you. If I were to guess what the problem might be, it could be that GDM may be executing some code in the SIGUSR1 signal handler that is not signal handler \ safe. Since it works most of the time, but fails in weird situations where many users log out at once, this might be triggering a normally rare event that makes the signal handler mad. Note in slave.c, the gdm_slave_usr2_handler function. Might be worth looking into this function more closely. At this point, I'm just giving you some pointers to hopefully narrow down what the problem may be. Perhaps you could investigate, and if possible add some more gdm_debug messages so we can have a better understanding of where the failure may be happening?" -- gdm hangs altogether after timeout on the gdm socket https://launchpad.net/bugs/62139 -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs