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

[Lennart Poettering]

On Fr, 01.12.17 13:42, Pekka Paalanen (ppaalanen at gmail.com) wrote:

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

This really depends on how weston sets up a VT. I really don't know
Weston and what it does. 

> - access to DRM and input devices via logind

So, I can't comment on Weston really.

Here are brief (and possibly slightly out-of-date, but probably not)
notes on how to write display managers with logind:

https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/

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

So, as long as weston runs from a PAM enabled service (and its PAM
snippet pulls in pam_systemd) all should be good and race-free: as the
PAM session is set up XDG_RUNTIME_DIR will be made available and the
systemd --user instance is invoked in the background.

What currently is not supported is to run things independently of any
session, i.e. run weston as systemd --user service with nothing that
creates a session in the first place. In that case XDG_RUNTIME_DIR
will not be set up, and no devices are made available to weston...

> > > > > +# 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?

well, pam_systemd needs to be pulled in from it, that's the most
important thing. A PAM snippet that pulls in pam_systemd means you get
a session allcoated in logind, which in turn sets up XDG_RUNTIME_DIR
for you.

Lennart

-- 
Lennart Poettering, Red Hat