[systemd-devel] [PATCH weston] doc/systemd: system service example

[Martyn Welch]

On Thu, 2017-11-30 at 12:09 +0200, Pekka Paalanen wrote:
> On Wed, 29 Nov 2017 19:05:07 +0100
> Lennart Poettering <lennart at poettering.net> wrote:
> 
> > On Di, 28.11.17 12:14, Pekka Paalanen (ppaalanen at gmail.com) wrote:
> > 
> > > +
> > > +[Unit]
> > > +Description=Weston, a Wayland compositor, as a system service
> > > +Documentation=man:weston(1) man:weston.ini(5)
> > > +Documentation=http://wayland.freedesktop.org/
> > > +
> > > +# Make sure we are started after logins are permitted.
> > > +After=systemd-user-sessions.service
> > > +
> > > +# If Plymouth is used, we want to start when it is on its way out.
> > > +After=plymouth-quit-wait.service
> > > +
> > > +# D-Bus is necessary for contacting logind. Logind is required.
> > > +Wants=dbus.socket
> > > +After=dbus.socket
> > > +
> > > +# This scope is created by pam_systemd when logging in as the user.
> > > +# This directive is a workaround to a systemd bug, where the setup of the
> > > +# user session by PAM has some race condition, possibly leading to a failure.
> > > +# See README for more details.
> > > +After=session-c1.scope  
> > 
> > Hmm, what is this about?
> > 
> > This is racy, as the session ID is not really reliably predictable,
> > and is synthesized in different contexts in different ways, for
> > example depnding on whether audit is enabled in the kernel it might be
> > session-1.scope rather than session-c1.scope.
> 
> Hi Lennart,
> 
> this is the bit Martyn talked you in person some time ago, maybe Martyn
> could refresh your memory?
> 
> Yes, I am definitely not happy about this directive, but it serves as
> the reminder of the issue Martyn was debugging a long time ago, and
> this was the workaround chosen for the particular project at that time.
> I guessed it's not portable.
> 
> I have it here so it would trigger the discussion, in the hopes that
> someone could recall the details of the fundamental problem. I heard it
> was deemed to be a hard-to-reproduce systemd bug, but I have no other
> details.
> 
> If we could determine the bug doesn't exist anymore, that would be
> awesome and I could just drop this.
> 

First off, apologies if I explained this badly when I attempted to
explain the issue at FOSDEM, I'm still not convinced I truly understand
what's happening here, but let's give it another go...

Testing of the product in the project mentioned by Pekka revealed that
we would sometimes see Weston fail to boot. IIRC, in the order of 2 in
10 times when switching from an initial charging state (that the device
would boot into when power was applied to the device without the power
button being pressed) and the normal running state (when the power
button was then pressed). The charging state is pretty much a small
subset of the normal running state. From memory, the "xuser" session is
not created in that state. The filtered logs that I was given:

2017-01-05T14:08:19.418888+00:00 XXX systemd-logind[315]: New seat
seat0.
2017-01-05T14:08:19.672756+00:00 XXX systemd-logind[315]: Watching
system buttons on /dev/input/event0 (power-gpio-keys)
2017-01-05T14:08:20.176354+00:00 XXX systemd[1]: Starting User Manager
for UID 1000...
2017-01-05T14:08:20.394955+00:00 XXX systemd[1]: Starting Weston...
2017-01-05T14:08:21.867999+00:00 XXX systemd-logind[315]: New session c1
of user xuser.
2017-01-05T14:08:21.915400+00:00 XXX systemd-logind[315]: Watching
system buttons on /dev/input/event0 (power-gpio-keys)
2017-01-05T14:08:46.279480+00:00 XXX weston[403]: [14:08:46.157] fatal:
environment variable XDG_RUNTIME_DIR is not set.
2017-01-05T14:08:46.421821+00:00 XXX systemd[1]: Failed to start Weston.
2017-01-05T14:08:46.471701+00:00 XXX systemd-logind[315]: Removed
session c1.
2017-01-05T14:08:47.424030+00:00 XXX systemd[1]: Started User Manager
for UID 1000.
2017-01-05T14:08:47.469949+00:00 XXX systemd-logind[315]: Failed to stop
user service: Transaction is destructive.
2017-01-05T14:08:47.540518+00:00 XXX systemd-logind[315]: Failed to stop
user slice: Transaction is destructive.

Debugging suggested that XDG_RUNTIME_DIR was not being created when it
failed. There are 2 processes setting a PAMName, the failing Weston
service and the user at .service (IIRC this gets called as part of user
session creation, which I think was triggered by "User=xuser" in our
weston.service). The user at .service has "PAMName=systemd-user" where as
weston.service has "PAMName=login". When user at .service called PAM first
everything worked as expected, if weston.service called PAM first it
failed. This was our attempt at forcing the former rather than the
latter.

> > > +# Set up a full user session for the user, required by Weston.
> > > +PAMName=login  
> > 
> > Piggy-backing on "login" is a bad idea. "login" is a text tool, and
> > thus the PAM rules for it usually pull in some TTY specific PAM
> > modules. YOu shoudl really use your own PAM fragment here, and
> > configure only the bits you need.
> 

Oh, so could it just be that we needed something other than
"PAMName=login"?

Thanks,

Martyn

> Ok. Is there any guide or example I could point people to, so that they
> can write their own stuff correctly? Any example I could put into
> Weston docs?
> 
> Personally I have no understanding of what PAM does. I just copied
> weston-launch (setuid-root helper for non-systemd systems) that also
> uses "login" for PAM name if it was asked to create a new session(?).
> 
> 
> Thanks,
> pq
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel