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

Fri Dec 1 11:42:52 UTC 2017

On Thu, 30 Nov 2017 11:16:19 +0000
Martyn Welch <martyn.welch at collabora.co.uk> wrote:

> 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.  

> > If we could determine the bug doesn't exist anymore, that would be
> > awesome and I could just drop this.

Hi Lennart,

taking a step back, the session-c1.scope directive is definitely not
wanted and we should drop it. We should also use a custom PAM name
setup. If we do that, is the service file otherwise good for
guaranteeing:

- a full user session setup (I presume we want it), specifically
  XDG_RUNTIME_DIR being set up

- running exclusively on a VT that is made current

- access to DRM and input devices via logind

so that all these are already in place by the time the Weston process
is started?

As you can see from Martyn below, the first issue that prevented Weston
from running was that XDG_RUNTIME_DIR was not set. Furthermore, this
failure did not occur always, sometimes things just worked as we
expected.

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

What are they key bits in the PAM configuration we must have, and are
there any often used bits we must not have to avoid the race Martyn
describes?

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20171201/4c5a40e0/attachment.sig>