GNOME Bugzilla – Bug 343091
First attempt to login on GDM fails
Last modified: 2006-10-23 23:15:11 UTC
I'm currently using Ubuntu 6.06 LTS, but this issue also occurred before the last 2 major updates. My gdm version is currently: gdm-2.14.6-0ubuntu1 Every time, after (re)booting my machine, the first attempt to login on gdm fails. When GDM is started the default Ubuntu theme shows up. I am able to log in but gnome does not load. After a minute or less, gdm will restart, and it shows up again with the (for gnome default) 'circels' theme. Now I am able to login, but I am only able to restart/shutdown my machine through gdm (so I have to log out first). When I restart GDM manually ('/etc/init.d/gdm restart') before the initial login, the default Ubuntu theme is also loaded, but now I AM able to log in without a hassle. I found some lines in my '/var/log/syslog' wich I will attach (if I'am able to in bugzilla -first time use). The lines in the syslog are most likely to be to be produced by gdmsetup: [terminal output] root@neo:~# gdmsetup Failed to connect to socket, sleep 1 second and retry Trying failed command again. Try 2 of 5. Failed to connect to socket, sleep 1 second and retry Trying failed command again. Try 3 of 5. Failed to connect to socket, sleep 1 second and retry Trying failed command again. Try 4 of 5. Failed to connect to socket, sleep 1 second and retry Trying failed command again. Try 5 of 5. Command failed 5 times, aborting. Kon het configuratiebestand van GDM niet benaderen. root@neo:~# [/terminal output] The last line is the dutch translation for: "Could not access GDM configuration file."
Created attachment 66328 [details] A snippet from my /var/log/syslog Here is a snippet from my /var/log/syslog file. These lines will show up if I login to GDM for the first time and GDM will restart while loading de default 'circles' theme. These lines are most likely to be produced by the gdmsetup command (see above).
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/gdm/+bug/46193
Anyone knows where this 'socket' is located?
This socket is the /tmp/.gdm_socket file. There may be some configuration issues with your system that do not allow programs run as the "gdm" user to access the socket? Your debug output only shows output from the gdmgreeter. Is there any debug messages from the GDM daemon process complaining about being unable to set up the socket for some reason? Note that this socket is set up in the daemon/gdm-net.c file in the gdm_connection_open_unix() function. You might try running the daemon in a debugger (remember to use the --nodaemon option) or adding gdm_debug() calls to get extra debug information if the syslog output is not enough. Note it is best to telnet into the machine and run the gdm daemon in a debugger like this, since it is hard to run the daemon in a debugger on the console...since GDM will start X on the system and take over the display.
Thanks for your comment! :) In my syslog file these are the only lines that have anything to do with gdm. I located the gdm socket, and these are it's properties: srw-rw-rw- 1 root root 0 2006-05-30 18:17 .gdm_socket The tricky thing about debugging gdm is that if gdm is restarted only once, it seems to work ok. None of the error messages appear in the syslog, and everything works fine. I'm going to remove gdm from my default runlevel and see if a manual startup of gdm will give me the same result. If not this probably has nothing to do with gdm but more with the Ubuntu startup procedure. I'll get back with more information...
I've heard of some problems with some distros shipping GDM in both /usr/bin and /usr/sbin. Make sure you are running the one in /usr/sbin. Brian
I removed gdm from my default startup procedure, and started it by hand. Now everything was fine. This tells me that this issue is not an issue of gdm, but more an issue of how my machine boots up and the state my machine is in at the time gdm is started.
Ok, it seems this is not a GDM bug, so I'm closing it as NOTABUG. If you find there is a problem with GDM or a way to improve GDM to better handle the situation, please reopen the bug or file a new bug.
Thanks for your help, Brian. Would you perhaps know what could create a situation like this?
Different distros have different mechanisms for starting programs at boot time. I'd look into /etc/rc* directories and see if there is a file there for starting GDM and see if it is pointing to the right place, which should be /usr/sbin/gdm
Thanks again for your help. I checked the initscript and it is definitely pointing to /sbin/gdm. By now I also know that this is caused because gdm is started to early in the boot process: If I remove /etc/rc2.d/S13gdm, and start it by hand it works. If I add '/etc/init.d/gdm start' to rc.local this also works. If i rename S13gdm to S99gdm and rename all S99* scripts to S98* it also works. I'm using NIS and NFS. My guess is that these have something to do with this. Is this possible?
Glad to hear that pointed you to a solution. Sounds like you now know how to get GDM working. Do NIS and NFS services start after S13gdm gets run? If so, then, yes, I'd bet that this might have something to do with it. You could test and see if using /etc/passwd directly works or logging into an account with a home directory not over NFS (such as the root user) with GDM started at the S13gdm location and if it works, then you know. If you find out, let me know since I'm curious now. :)
Hi Brian, It didn't matter whether I logged in with a local user or a NIS user. Also my home directories are local folders. I only use NFS to have a shared folder between clients. By the way, the error messages in syslog appeared during gdm startup (I didn't even log in). S13gdm is started first, after that S18nis and S18portmap are. I don't know where exactly the NFS filesystem gets mounted, but obviously it's after the portmap daemon. I now have placed back the order of my boot scripts as they originally were. Also I have removed S99mountnfs wich was not originally a script that belonged in the boot process (at least not that way). Still my NFS filesystem gets mounted along the boot process (because I specified 'auto' in /etc/fstab) Because of some problems earlier with NFS (it didn't get mounted, because my network wasn't fully configured at that time in the process), I placed the S99mountfs script in my boot process. That worked fine for me, but later on (updates) It seemed to have broken the process. I still do not quite understand what this has to do with gdm not accessing /tmp/.gdm_socket (which is on a local drive obviously). Also look at the last 4 comments from the Ubuntu bug: https://launchpad.net/distros/ubuntu/+source/gdm/+bug/46193 Anyhow, this is now really solved for me. Thank you for helping me out, and sorry for posting a bug that was initially my own fault! Regards, Raoul
Yes, the startup scripts are complicated. Glad to hear that your problem is solved - another happy GDM user.
Changing the GDM startup script to S21gdm also works well at least on my machine. The suggestion came from this bug: On Mon, 23 Oct 2006 12:46:38 +0000 Adriano Varoli Piazza <moranar@gmail.com> wrote: > My mistake, I'd mystyped s21gdm instead of S21gdm. It now works > (though it seems like it takes more to open gdm, probably because it > does). Maybe some other initscript can be moved after it? I attach my > (modified) setup for /etc/rc2.d as a text file. > -- Cannot run gdmsetup https://launchpad.net/bugs/66034