[Pkg-systemd-maintainers] gdm3: GLib.js still an issue GDM doesn't get to greeter

Emilio Pozuelo Monfort pochu at debian.org
Sun Nov 17 11:47:00 GMT 2013

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'?


More information about the Pkg-systemd-maintainers mailing list