GNOME Bugzilla – Bug 326796
gdmdynamic causes gdm to enter unstable state
Last modified: 2006-02-10 00:51:20 UTC
Please describe the problem: When a command is issued to gdmdynamic to remove an idle display it fails to remove the display and gdm is left in an unstable state. After this has occurred, logging out does not complete properly and the gdmgreeter screen fails to appear. Steps to reproduce: 1. /usr/bin/gdmdynamic -b -d $DISPLAY_NUM 2. Log out of a gnome session Actual results: Cannot log out properly. Expected results: I would expect that the gdmdynamic command would correctly remove the desired display and that users could still log out appropriately by being presented with the gdmgreeter screen upon logging out. Does this happen every time? Yes. Other information: The issue was encountered when using SunRay Server Software (SRSS) 3.1 on Ubuntu 5.10. SRSS uses the /opt/SUNWut/lib/Xcleanup script to remove displays that have remained idle for more than 900 seconds. Using subsequent scripts, the /opt/SUNWut/lib/xmgr/gdm/remove-dpy script is called which executes the above command. For reference to the error message displayed by the SunRay - the error number displayed is 26 - see http://www.filibeto.org/sun/sunray-users/lib/sunsolve/77966.html for more information.
This bug is in the SRSS code. The remove-dpy script expects the output of gdmdynamic -l to be one entry per line and now the displays are echoed all one one line separated by semicolons. If you fix the remove-dpy script to work with the gdmdynamic -l output, the problem should go away. The SRSS people plan to fix this bug eventually.
The remove-dpy script does not contain any 'gdmdynamic -l' calls. The reset-dpy script, on the other hand, does and with the following altered 'gdmdynamic -l' command: dpys=`/usr/bin/gdmdynamic -l | tr ";" "\012" | sed -e "s/:\(.*\),.*,.*/\1/" | tr "\012" " "` the bug still occurs. A workaround/fix to allow for the proper use of the /opt/SUNWut/lib/Xcleanup script would be appreciated.
Brian, Here is some additional output of gdmdynamic which recreates the problem: root@naaman:/var# gdmdynamic -va 18=/etc/opt/SUNWut/basedir/lib/utxsun Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'GET_CONFIG_FILE' Got response: 'OK /etc/gdm/gdm.conf' Sending command: 'CLOSE' Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'AUTH_LOCAL 970c6b6d294a13f3b182a2033c1c7b10' Got response: 'OK' Sending command: 'ADD_DYNAMIC_DISPLAY 18=/etc/opt/SUNWut/basedir/lib/utxsun' Got response: 'OK' Sending command: 'CLOSE' OK root@naaman:/var# gdmdynamic -vr 18 Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'GET_CONFIG_FILE' Got response: 'OK /etc/gdm/gdm.conf' Sending command: 'CLOSE' Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'AUTH_LOCAL 970c6b6d294a13f3b182a2033c1c7b10' Got response: 'OK' Sending command: 'RELEASE_DYNAMIC_DISPLAYS 18' Got response: 'OK' Sending command: 'CLOSE' OK root@naaman:/var# gdmdynamic -vd 18 Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'GET_CONFIG_FILE' Got response: 'OK /etc/gdm/gdm.conf' Sending command: 'CLOSE' Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'AUTH_LOCAL 970c6b6d294a13f3b182a2033c1c7b10' Got response: 'OK' Sending command: 'REMOVE_DYNAMIC_DISPLAY 18' Got response: 'OK' Sending command: 'CLOSE' OK root@naaman:/var# gdmdynamic -va 18=/etc/opt/SUNWut/basedir/lib/utxsun Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'GET_CONFIG_FILE' Got response: 'OK /etc/gdm/gdm.conf' Sending command: 'CLOSE' Sending command: 'VERSION' Got response: 'GDM 2.8.0.5' Sending command: 'AUTH_LOCAL 970c6b6d294a13f3b182a2033c1c7b10' Got response: 'OK' Sending command: 'ADD_DYNAMIC_DISPLAY 18=/etc/opt/SUNWut/basedir/lib/utxsun' Got response: 'ERROR 2 Existing display' Sending command: 'CLOSE' ERROR 2 Existing display root@naaman:/var# gdmdynamic -l :11,,-1;:12,,-1;:14,,-1;:18,,-1
Thanks for the debug output. Yes, it looks like you have found a bug in GDM. It seems that the call to gdmdynamic -d isn't working since it isn't actually removing or deleting the display (since you can still obviously see it when you run gdmdynamic -l". However, the gdmdynamic -d command isn't generating any error messages so it is hard to tell why it is failing. Does turning on "enable=true" in the [debug] section of the gdm.conf file send any useful messages to the syslog explaining why it isn't shutting down the display? Look in daemon/gdm.c and notice the code for (type == DYNAMIC_REMOVE) in the handle_dynamic_server () function and note that it sends some messages to the debug log. It should send a message "gdm_display_unmanage: Display stopped". Does this message get to the log? Also the whack_old_slave function sends some messages to debug, so that might help us track down the problem. It might be necessary to add some extra debug messages to the whack_old_slave function if it is not really working to help figure out exactly why. Are you able to recompile and retest a bit like this to help track down the problem? Note that after recompiling and reinstalling gdm you have to run gdm-restart to restart GDM for the new logic to take effect.
Okay, thanks for the report. I've spent the past week working on gdmdynamic and fixed the REMOVE bug that you reported. If you want to test using GDM CVS head that would be useful. I'm doing a release on the 11th, but it would be helpful to get any feedback before then. A little history so you understand why this bug was there. The SunRay people wrote gdmdynamic, and then worked with George Lebl to get the code into GDM CVS head. George had a lot of issues with the way the SunRay team wrote gdmdynamic and asked them to change a bunch of stuff. The SunRay team had to ship their original gdmdynamic before they got the fixes George wanted into GDM CVS head. Therefore this bug with REMOVE slipped in and didn't get noticed until now since the SunRay people are actually using a different version of the code. That's why you have to hack the SRSS scripts to work with the way "gdmdynamic -l" returns data since it was different in the original code the SunRay people wrote and shipped. Also I have recently done a lot of work improving gdmdynamic so it works much better. The way the SunRay people wrote gdmdynamic it would only work with 10-20 or so clients. Now the code is much smarter about how sockets are handled and should support over 100 clients without a problem. So I'd definately recommend using the latest code if you want to use gdmdynamic.