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

[Emilio Pozuelo Monfort]

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