sometimes gdm lists no users
I'm using fedora 20. Since a few upgrades ago, sometimes after boot gdm will not display any users and so log in is impossible. If I go in a text terminal with ctrl-alt-f2 and log in, then run sudo killall gdm, gdm restarts and does show my single user so that i can login.
I have opened this bug related to this, but no reaction so far: https://bugzilla.redhat.com/show_bug.cgi?id=1065687
EDIT: sadly yum reinstall didn't help. I hoped a bit after the first reboot helped, but now the problem happened again. Also, this is just a plain user as created by the fedora installer, local user, nothing special, all standard.
And here is the output of sudo journalctl -u gdm (otherwise the log is superlong, I'm using this installation for a long time, this is a F18 upgraded to F19 upgraded to F20...).
I think this is a boot where everything went OK:
-- Reboot --
Feb 17 21:50:00 emmanuel-linux systemd[1]: Starting GNOME Display Manager...
Feb 17 21:50:01 emmanuel-linux systemd[1]: Started GNOME Display Manager.
Feb 17 21:50:07 emmanuel-linux gdm[666]: Failed to give slave programs access to the display. Trying to proceed.
Feb 17 21:50:36 emmanuel-linux systemd[1]: Stopping GNOME Display Manager...
Feb 17 21:50:37 emmanuel-linux systemd[1]: Stopped GNOME Display Manager.
And in this case there was a problem:
-- Reboot --
Feb 19 07:49:39 emmanuel-linux systemd[1]: Starting GNOME Display Manager...
Feb 19 07:49:40 emmanuel-linux systemd[1]: Started GNOME Display Manager.
Feb 19 07:49:47 emmanuel-linux gdm[675]: Failed to give slave programs access to the display. Trying to proceed.
Feb 19 07:50:21 emmanuel-linux systemd[1]: gdm.service holdoff time over, scheduling restart.
Feb 19 07:50:21 emmanuel-linux systemd[1]: Stopping GNOME Display Manager...
Feb 19 07:50:21 emmanuel-linux systemd[1]: Starting GNOME Display Manager...
Feb 19 07:50:21 emmanuel-linux systemd[1]: Started GNOME Display Manager.
Feb 19 07:50:21 emmanuel-linux gdm[1741]: Failed to give slave programs access to the display. Trying to proceed.
Feb 19 07:50:34 emmanuel-linux gdm[1741]: Failed to remove slave program access to the display. Trying to proceed.
But probably the difference is only because I restarted gdm with the killall.
In var/log/gdm, the only files which have been recently updated are :0.log and :0.log.1 and this is the X11 log, I see nothing interesting there.
_EDIT:_ well i'm currently installing the f20 upgrade which has this fix inside: https://lists.fedoraproject.org/pipermail/scm-commits/Week-of-Mon-20140210/1189685.html
So I'm kind of hoping the issue could be related and fixed by this problem. I have those hangs currently in maybe 20% of the boots.
Welcome. You have to know that the "sometimes" situation is very difficult to be fixed. Either in a bug report or/and a question. If the problem was persistent and reproducible, then it would be much, much better. Try to reinstall GDM
sudo yum reinstall gdmand check for any differences. Also check the user ID (UID) and see if it's below 1000. If it is, then by default (I think) the GDM doesn't list such users in login screenid $USERthanks. my user id is 1000. it's the typical case I guess, single user on this laptop. it's reproducible, I reboot a couple of times and I get both cases I think. I would expect there to be some log somewhere... I tried but I only find the X11 logs. I'm trying to reinstall now, I'll see if it makes any difference, thanks for the tip!
When I say reproducible I mean by the developers (bug report) or by us here (question). I mean, you have to provide a step by step case in which this bad behavior of GDM can be repeated. I also have one user at my Laptop (me) but GDM works as it should. Also, check any logs related to GDM inside
/var/log/directory and asudo journalctl -u gdmcould help.I've only seen this when the authconfig configured login mechanism is failing. It never comes back after a restart of GDM though. For me it was caused by a dodgy network connection (the lug on the ethernet plug was missing, and the lead would come out occasionally) and if it couldn't talk to NIS, then it wouldn't show the users. It doesn't look like that's the issue here - but it might be worth checking which authentication mechanisms you're using.