On 16/11/13 19:40, Emilio Pozuelo Monfort wrote: > On 16/11/13 18:34, Les Schaffer wrote: >> Emilio: >> >> >> On 11/16/2013 11:33 AM, Emilio Pozuelo Monfort wrote: >>> Les, can you attach /etc/pam.d/common-session ? Can you also run >>> `pam-auth-update --force' as root and see if that helps? >> >> i tried pam-auth-update --force a few days ago and it didn't help. i >> just ran it again and restarted gdm3, still same exact error as in my >> first :0-greeter.log common-session attached. >> >>> Can you also check if there are any errors in /var/log/auth.log and attach >>> it? >> >> yes, there is an error. relevant portion attached. > > Thanks! This is interesting: > > Nov 16 12:06:35 speggy gdm-launch-environment][9438]: > pam_systemd(gdm-launch-environment:session): Failed to create session: No such > process > > Reading the relevant libpam-systemd code, it seems like libpam-systemd is > talking to logind through dbus but logind is not running so dbus return that > error. However if logind is not running, gnome-shell should have noticed it > and > decided to use the ConsoleKit support. > > Is logind running? Have you done anything to enable/disable it? > > What's the output of `ls -l /run/systemd/' ?
I have tried going this way. I have moved /usr/share/dbus-1/system-services/org.freedesktop.login1.service out of the way so logind wouldn't autostart, and booted with sysvinit. I get a gdm prompt just fine. logind is not running, and /run/systemd doesn't exist, which means gnome-shell is talking to ConsoleKit and not logind (and indeed my print() for debugging purposes confirms this). Thus I don't get gnome-shell trying to talk to a non-running logind and everything works fine. I get a somewhat similar libpam_systemd error: Nov 17 12:03:58 titan gdm-launch-environment][3106]: pam_systemd(gdm-launch-environment:session): Failed to create session: The name org.freedesktop.login1 was not provided by any .service files But the user session is created nonetheless (which is what should happen as libpam_systemd is marked as 'optional', or at least that is my understanding), and thus the gdm greeter starts fine. But your case is different. logind *is* running (I was wrong in thinking it wouldn't). libpam-systemd sends a dbus message, CreateSession, and logind replies with an error ESRCH "No such process" (I have no idea why). Since CreateSession fails, libpam-systemd doesn't set XDG_SESSION_ID. But the user session is created, and gdm3 tries to start. At this point, the gnome-shell gdm greeter is started, and wonders whether to talk to logind or to ConsoleKit. It checks if /run/systemd/seats exists, and since it does, it decides to talk to logind. This is fine. Since logind is running, it checks for XDG_SESSION_ID which should have been set, but it isn't, so it doesn't create a session (which would probably not work as CreateSession in logind failed earlier). So the question at this point is: why does logind fail to create the session? What is it referring to when it returns 'No such process'? Emilio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
