GNOME Bugzilla – Bug 306282
gdm debug messages do not provide enough detail for troubleshooting
Last modified: 2006-01-10 00:49:55 UTC
Version details: 2.6.0.7 Distribution/Version: Gentoo 2005 I'm attempting to find out why gdm keeps crashing on my Gentoo 2005 system. When I enabled full debug, I get technical information - but not details real details as to why signals are being generated to terminate the main process. Jun 1 08:50:45 localhost gdm[10915]: gdm_main: Here we go... Jun 1 08:50:45 localhost gdm[10915]: XDMCP: Start up on host pic, port 177 Jun 1 08:50:45 localhost gdm[10915]: gdm_start_first_unborn_local: Starting :0 Jun 1 08:50:45 localhost gdm[10915]: gdm_display_manage: Managing :0 Jun 1 08:50:45 localhost gdm[10915]: loop check: last_start 0, last_loop 0, now: 1117633845, retry_count: 0 Jun 1 08:50:45 localhost gdm[10915]: Resetting counts for loop of death detection Jun 1 08:50:45 localhost gdm[10917]: gdm_slave_start: Starting slave process for :0 Jun 1 08:50:45 localhost gdm[10917]: gdm_slave_start: Loop Thingie Jun 1 08:50:45 localhost gdm[10917]: Sending VT_NUM == -1 for slave 10917 Jun 1 08:50:45 localhost gdm[10917]: Sending VT_NUM 10917 -1 Jun 1 08:50:45 localhost gdm[10915]: gdm_display_manage: Forked slave: 10917 Jun 1 08:50:45 localhost gdm[10915]: Accepting XDMCP connections... Jun 1 08:50:45 localhost gdm[10915]: Handling message: 'VT_NUM 10917 -1' Jun 1 08:50:45 localhost gdm[10915]: Got VT_NUM == -1 Jun 1 08:50:45 localhost gdm[10917]: gdm_server_start: :0 Jun 1 08:50:45 localhost gdm[10917]: gdm_auth_secure_display: Setting up access for :0 Jun 1 08:50:45 localhost gdm[10917]: gdm_auth_secure_display: Setting up access Jun 1 08:50:45 localhost gdm[10917]: gdm_auth_secure_display: Setting up access for :0 - 1 entries Jun 1 08:50:45 localhost gdm[10917]: Sending COOKIE == <secret> for slave 10917 Jun 1 08:50:45 localhost gdm[10915]: (child 10917) gdm_slave_usr2_handler: :0 got USR2 signal Jun 1 08:50:45 localhost gdm[10917]: Sending COOKIE 10917 5... Jun 1 08:50:45 localhost gdm[10915]: Handling message: 'COOKIE 10917 5...' Jun 1 08:50:45 localhost gdm[10915]: Got COOKIE == <secret> Jun 1 08:50:45 localhost gdm[10915]: (child 10917) gdm_slave_usr2_handler: :0 got USR2 signal Jun 1 08:50:45 localhost gdm[10922]: gdm_server_spawn: '/usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7' Jun 1 08:50:45 localhost gdm[10915]: (child 10917) gdm_server_usr1_handler: Got SIGUSR1, server running Jun 1 08:50:45 localhost gdm[10917]: gdm_server_spawn: Forked server on pid 10922 Jun 1 08:50:45 localhost gdm[10917]: gdm_server_start: Completed :0! Jun 1 08:50:45 localhost gdm[10917]: Sending VT_NUM == 7 for slave 10917 Jun 1 08:50:45 localhost gdm[10917]: Sending VT_NUM 10917 7 Jun 1 08:50:45 localhost gdm[10915]: Handling message: 'VT_NUM 10917 7' Jun 1 08:50:45 localhost gdm[10915]: Got VT_NUM == 7 Jun 1 08:50:45 localhost gdm[10917]: Sending XPID == 10922 for slave 10917 Jun 1 08:50:45 localhost gdm[10917]: Sending XPID 10917 10922 Jun 1 08:50:45 localhost gdm[10915]: (child 10917) gdm_slave_usr2_handler: :0 got USR2 signal Jun 1 08:50:45 localhost gdm[10915]: Handling message: 'XPID 10917 10922' Jun 1 08:50:45 localhost gdm[10915]: Got XPID == 10922 Jun 1 08:50:45 localhost gdm[10917]: gdm_slave_run: Opening display :0 Jun 1 08:50:45 localhost gdm[10915]: (child 10917) gdm_slave_usr2_handler: :0 got USR2 signal Jun 1 08:50:47 localhost gdm[10917]: Sending START_NEXT_LOCAL Jun 1 08:50:47 localhost gdm[10917]: gdm_slave_greeter: Running greeter on :0 Jun 1 08:50:47 localhost gdm[10915]: Handling message: 'START_NEXT_LOCAL' Jun 1 08:50:47 localhost gdm[10915]: (child 10917) gdm_slave_child_handler Jun 1 08:50:47 localhost gdm[10917]: gdm_slave_greeter: Greeter on pid 10967 Jun 1 08:50:47 localhost gdm[10917]: Sending GREETPID == 10967 for slave 10917 Jun 1 08:50:47 localhost gdm[10917]: Sending GREETPID 10917 10967 Jun 1 08:50:47 localhost gdm[10915]: Handling message: 'GREETPID 10917 10967' Jun 1 08:50:47 localhost gdm[10915]: Got GREETPID == 10967 Jun 1 08:50:47 localhost gdm[10915]: (child 10917) gdm_slave_usr2_handler: :0 got USR2 signal Jun 1 08:50:47 localhost gdm[10917]: term_quit: Final cleanup Jun 1 08:50:47 localhost gdm[10915]: (child 10917) gdm_slave_child_handler Jun 1 08:50:47 localhost gdm[10917]: gdm_slave_quick_exit: Will kill everything from the display Jun 1 08:50:47 localhost gdm[10915]: (child 10917) gdm_slave_child_handler: 10967 died Jun 1 08:50:47 localhost gdm[10915]: (child 10917) gdm_slave_child_handler: 10967 returned 1 Jun 1 08:50:47 localhost gdm[10917]: gdm_server_stop: Server for :0 going down! Jun 1 08:50:47 localhost gdm[10917]: gdm_server_stop: Killing server pid 10922 Jun 1 08:50:48 localhost gdm[10917]: gdm_server_stop: Server pid 10922 dead Jun 1 08:50:48 localhost gdm[10917]: gdm_slave_quick_exit: Killed everything from the display Jun 1 08:50:48 localhost gdm[10915]: mainloop_sig_callback: Got signal 17 Jun 1 08:50:48 localhost gdm[10915]: gdm_cleanup_children: child 10917 returned 65 What caused the following line to occur? Jun 1 08:50:47 localhost gdm[10917]: gdm_slave_quick_exit: Will kill everything from the display Invalid permissions? Bad configuration? None of the debug information above this line says what error occurred to make the child go south.
I feel your pain, but it isn't really possible for me to figure out what problem is happening on your machine. We can only add better debug messages if you can identify where the code is failing. Then we can add a debug message to help future people who bump into the problem. Do you have time to debug this?
I'm not filing a bug for the fact that gdm is crashing. I'm filing a bug for the fact that in the debug log no explanation is given why a child threw a generic error code "1" and then decided to bring down the display. If a comment were given when the exit path does not equal 0 would be beneficial, rather than ambiguous. I just figured that the people who develop gdm on a regular basis would be better suited in assigning debug information than a person who has not even looked at gdm code at all.
Yes, I understand the bug is that you feel that the debug messages should be more clear. I'm just highlighting that it is hard to know exactly what is causing the problem since I can't easily look at your environment. Therefore it is hard to know exactly how to fix the code. You mention that the gdm child is throwing a generic error code "1". However, I don't see such a message in the above log. Am I just missing it? I notice the child sends a SIGUSR1, though this is okay. It's normal daemon/slave interaction. Looking more closely at your log, I suspect that gdm2 is having trouble starting X, or is having trouble starting the greeter program. Can you try running the following tests: 1) From the console, try launching the Xserver by hand using the same command as specified in the "[server-Standard]" section of the gdm.conf file. This should bring up the Xserver. If not, you might have a problem with your Xserver, or you might need to tweak the Xserver launch command to work properly on your system. 2) Once the Xserver is running, try setting the environment variable DOING_GDM_DEVELOPMENT=1 and run "gdmlogin" or "gdmgreeter". Sometimes people have trouble starting the greeter because it is expecting a library or other resource to be on your machine that is missing. Running gdmlogin or gdmgreeter from the commandline makes it easier to see any error messages that might be generated. Let me know if this helps, or highlights what the problem might be.
I can start up the Xserver manually "/usr/X11R6/bin/X -audit 0" I can then bring up both the greeter and the standard login dialogs with no problem using the environment variable trick "export DISPLAY=:0; gdmlogin". Looking at the console, the input from the gdmlogin and gdmgreeter dialogs is getting sent back no problem. Verified that the permissions on /var/gdm are rwX for gdm:gdm. But, when I execute "gdm -nodaemon" by itself to test - it brings up X, goes down, brings up X, goes down, brings up X, goes down - pauses 5 seconds and then repeats.
Looking at the gdm debug output, it seems that gdm is trying to start the XServer with this command: /usr/X11R6/bin/X :0 -audit 0 -auth /var/gdm/:0.Xauth -nolisten tcp vt7 Can you start the Xserver with this command? If not, what part of the command is causing it to mess up? Also, it seems that it is trying to use virtual terminal #7. I'm not sure why your system is trying to use virtual terminals for console login. I'm assuming the crash is happening when you first bootup the machine on console? Could you attach your gdm.conf file to this bug report so I can take a look at it?
Created attachment 47557 [details] gdm.conf for the trouble setup
I have no problems setting up the X server with the above command.
This is weird. If you can start the Xserver and can start gdmlogin and gdmgreeter from the terminal, things should be working. Your /var/lib directory should be owned by root and have group gdm. It should have drwxrwx--T permissions. gdm2 saves it's Xauth cookies there, so if the permissions aren't right, it won't be able to start up the Xserver properly. Also make sure that your /tmp directory and /var/gdm isn't full. gdm2 also saves error log files to /var/log/gdm. The log files are setup for each display so ":0.log" is the logfile for DISPLAY :0. There might be a useful error message there.
I'm closing this bug as willnotfix since the persom who submitted the bug ended the dialog last June before we could identify exactly what was causing X to not start up properly. No other user has had a similar complaint since that time. The submitter can re-open the bug if interested in continuing the dialog.