GNOME Bugzilla – Bug 113902
gdm stops serving login window
Last modified: 2005-10-28 20:26:56 UTC
GDM daemon stops serving login window. It occured many times on a server running about 50 diskless (LTSP based) PC terminal. GDM crash is not causing working clients to log out. The only problem is that new clients can't get login window. After the crash "netstat -au" shows that gdm daemon don't read UDP receive queue.
Created attachment 16908 [details] gdm.conf file
Created attachment 16909 [details] netstat -aup output
Created attachment 16910 [details] ps -axf output ("gdm" keyword grep)
I cannot figure out why this would fail. I've tried on my own machine to start over 65 local xdmcp connections and gdm is still all fine. Can you give me the /var/log/messages output leading up to where gdm is stuck. Also if you could can you turn on debugging in the config file? That will generate even more syslog spew (a LOT actually) It would be interesting to see where gdm gets stuck. It seems to me that the main gdm daemon is actually hung. Could you perhaps also try to get a backtrace with gdb of the main daemon?
it would be very interesting to see if the latest development versions still exhibit this bug
I just upgraded to redhat 9, and gdm still exhibits this behaviour. Here is the rpm -qi Name : gdm Relocations: (not relocateable) Version : 2.4.1.3 Vendor: (none) Release : 5.1 Build Date: Sat Apr 3 15:18:14 2004 Install Date: Sat Apr 3 15:18:33 2004 Build Host: brinn Actually this version displays this problem worse than any other version I've used with earlier redhats. Here is some log output (debug is on) that I think is telling: Note the 'REFUSE'. Apr 23 11:27:42 brinn gdm[1167]: gdm_display_dispose: Disposing hipmas:0 Apr 23 11:27:42 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for hipmas:0 Apr 23 11:27:42 brinn gdm[1167]: gdm_auth_secure_display: Setting up network access Apr 23 11:27:42 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for hipmas:0 - 1 entries Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_display_alloc: display=hipmas:0, session id=1082737675, pending=17 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_send_accept: Sending ACCEPT to 192.168.164.136 with SessionID=1082737675 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode MANAGE from client 192.168.164.132 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_handle_manage: Got MANAGE from 192.168.164.132 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_handle_manage: Got Display=0, SessionID=1082737650 from 192.168.164.132 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_handle_manage: Failed to look up session id 1082737650 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_send_refuse: Sending REFUSE to 1082737650 Apr 23 11:27:42 brinn gdm[1167]: gdm_forward_query_lookup: Host 192.168.164.132 not found Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode REQUEST from client 192.168.164.130 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_handle_request: Got REQUEST from 192.168.164.130 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_handle_request: pending=17, MaxPending=40, sessions=-17, MaxSessions=100 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_display_dispose_check (batfox:0) Apr 23 11:27:42 brinn gdm[1167]: gdm_display_dispose: Disposing batfox:0 Apr 23 11:27:42 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for batfox:0 Apr 23 11:27:42 brinn gdm[1167]: gdm_auth_secure_display: Setting up network access Apr 23 11:27:42 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for batfox:0 - 1 entries Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_display_alloc: display=batfox:0, session id=1082737676, pending=17 Apr 23 11:27:42 brinn gdm[1167]: gdm_xdmcp_send_accept: Sending ACCEPT to 192.168.164.130 with SessionID=1082737676 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode REQUEST from client 192.168.164.173 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_request: Got REQUEST from 192.168.164.173 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_request: pending=17, MaxPending=40, sessions=-18, MaxSessions=100 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_display_dispose_check (mgoose:0) Apr 23 11:27:43 brinn gdm[1167]: gdm_display_dispose: Disposing mgoose:0 Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for mgoose:0 Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up network access Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for mgoose:0 - 1 entries Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_display_alloc: display=mgoose:0, session id=1082737677, pending=17 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_send_accept: Sending ACCEPT to 192.168.164.173 with SessionID=1082737677 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode MANAGE from client 192.168.164.151 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_manage: Got MANAGE from 192.168.164.151 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_manage: Got Display=0, SessionID=1082737654 from 192.168.164.151 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_manage: Failed to look up session id 1082737654 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_send_refuse: Sending REFUSE to 1082737654 Apr 23 11:27:43 brinn gdm[1167]: gdm_forward_query_lookup: Host 192.168.164.151 not found Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode MANAGE from client 192.168.164.170 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_manage: Got MANAGE from 192.168.164.170 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_manage: Got Display=0, SessionID=1082737655 from 192.168.164.170 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_manage: Failed to look up session id 1082737655 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_send_refuse: Sending REFUSE to 1082737655 Apr 23 11:27:43 brinn gdm[1167]: gdm_forward_query_lookup: Host 192.168.164.170 not found Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode REQUEST from client 192.168.164.171 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_request: Got REQUEST from 192.168.164.171 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_request: pending=17, MaxPending=40, sessions=-19, MaxSessions=100 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_display_dispose_check (kusima:0) Apr 23 11:27:43 brinn gdm[1167]: gdm_display_dispose: Disposing kusima:0 Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for kusima:0 Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up network access Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for kusima:0 - 1 entries Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_display_alloc: display=kusima:0, session id=1082737678, pending=17 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_send_accept: Sending ACCEPT to 192.168.164.171 with SessionID=1082737678 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_decode: Received opcode REQUEST from client 192.168.164.175 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_request: Got REQUEST from 192.168.164.175 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_handle_request: pending=17, MaxPending=40, sessions=-20, MaxSessions=100 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_display_dispose_check (otterr:0) Apr 23 11:27:43 brinn gdm[1167]: gdm_display_dispose: Disposing otterr:0 Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for otterr:0 Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up network access Apr 23 11:27:43 brinn gdm[1167]: gdm_auth_secure_display: Setting up access for otterr:0 - 1 entries Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_display_alloc: display=otterr:0, session id=1082737679, pending=17 Apr 23 11:27:43 brinn gdm[1167]: gdm_xdmcp_send_accept: Sending ACCEPT to 192.168.164.175 with SessionID=1082737679
Oops, one more thing. This only happens when gdm is completely restarted, and all 50 of our terminals are on. If I shut off most of the terminals and then turn them on at about 2 minute intervals, they all get login screens with no problems.
See http://bugs.debian.org/290916 for (very probably) the same bug. There is a patch a few people _successfully_ use, but the package maintainer does not react. I wonder why the last post to this bug is over a year old even though the bug is not closed. Regards, VS
Thanks for the update. Fixed in CVS head and 2.8 branch.