Discussion:
[PATCH weston] doc/systemd: system service example
Add Reply
Pekka Paalanen
2017-11-28 10:14:29 UTC
Reply
Permalink
Raw Message
From: Pekka Paalanen <***@collabora.co.uk>

There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.

This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.

The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.

The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.

Fixes: https://phabricator.freedesktop.org/T63

Cc: ***@collabora.co.uk
Cc: ***@collabora.co.uk
Cc: ***@gmail.com
Cc: ***@collabora.co.uk
Signed-off-by: Pekka Paalanen <***@collabora.co.uk>

---

Hi all,

I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
doc/systemd/README | 45 +++++++++++++++++++++++++++++++
doc/systemd/weston.service | 66 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 111 insertions(+)
create mode 100644 doc/systemd/README
create mode 100644 doc/systemd/weston.service

diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index 00000000..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+ Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login --enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+This can be done on the Weston command line:
+
+$ weston --modules=systemd-notify.so
+
+or in weston.ini:
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+ weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index 00000000..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[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
+
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+Before=graphical.target
+
+# Prevent starting on systems without virtual consoles, Weston requires one
+# for now.
+ConditionPathExists=/dev/tty0
+
+[Service]
+
+# Requires systemd-notify.so Weston plugin.
+Type=notify
+ExecStart=/usr/bin/weston
+
+# Optional watchdog setup
+TimeoutStartSec=60
+WatchdogSec=20
+
+# The user to run Weston as.
+User=westonuser
+
+# Set up a full user session for the user, required by Weston.
+PAMName=login
+
+# A virtual terminal is needed.
+TTYPath=/dev/tty7
+TTYReset=yes
+TTYVHangup=yes
+TTYVTDisallocate=yes
+
+# Fail to start if not controlling the tty.
+StandardInput=tty-fail
+
+# Log this user with utmp, letting it show up with commands 'w' and 'who'.
+UtmpIdentifier=tty7
+UtmpMode=user
+
+[install]
+WantedBy=graphical.target
--
2.13.6
systemd github import bot
2017-11-28 11:04:07 UTC
Reply
Permalink
Raw Message
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:
<https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:20171128101429.22298-1-ppaalanen%40gmail.com>

--
Generated by https://github.com/haraldh/mail2git
Jérémy Rosen
2017-11-29 08:32:02 UTC
Reply
Permalink
Raw Message
I had a quick glance but didn't actually test...

1) please open a pull request on github, you will have more feedback
that way
2) you probably want to add Alias=display-manager.service, so it can
pull it other graphical services

Regards
Jérémy
Post by Pekka Paalanen
There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.
This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.
The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.
The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.
Fixes: https://phabricator.freedesktop.org/T63
---
Hi all,
I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
doc/systemd/README | 45 +++++++++++++++++++++++++++++++
doc/systemd/weston.service | 66 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 111 insertions(+)
create mode 100644 doc/systemd/README
create mode 100644 doc/systemd/weston.service
diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index 00000000..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+ Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login --enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+
+$ weston --modules=systemd-notify.so
+
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+ weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index 00000000..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[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
+
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+Before=graphical.target
+
+# Prevent starting on systems without virtual consoles, Weston requires one
+# for now.
+ConditionPathExists=/dev/tty0
+
+[Service]
+
+# Requires systemd-notify.so Weston plugin.
+Type=notify
+ExecStart=/usr/bin/weston
+
+# Optional watchdog setup
+TimeoutStartSec=60
+WatchdogSec=20
+
+# The user to run Weston as.
+User=westonuser
+
+# Set up a full user session for the user, required by Weston.
+PAMName=login
+
+# A virtual terminal is needed.
+TTYPath=/dev/tty7
+TTYReset=yes
+TTYVHangup=yes
+TTYVTDisallocate=yes
+
+# Fail to start if not controlling the tty.
+StandardInput=tty-fail
+
+# Log this user with utmp, letting it show up with commands 'w' and 'who'.
+UtmpIdentifier=tty7
+UtmpMode=user
+
+[install]
+WantedBy=graphical.target
--
SMILE <http://www.smile.eu/>

20 rue des Jardins
92600 AsniÚres-sur-Seine


*Jérémy ROSEN*
Architecte technique
Responsable de l'expertise Smile-ECS

email ***@smile.fr <mailto:***@smile.fr>
phone +33141402967
url http://www.smile.eu

Twitter <https://twitter.com/GroupeSmile> Facebook
<https://www.facebook.com/smileopensource> LinkedIn
<https://www.linkedin.com/company/smile> Github
<https://github.com/Smile-SA>


Découvrez l’univers Smile, rendez-vous sur smile.eu
<http://smile.eu/?utm_source=signature&utm_medium=email&utm_campaign=signature>

eco Pour la planÚte, n'imprimez ce mail que si c'est nécessaire
systemd github import bot
2017-11-29 09:05:48 UTC
Reply
Permalink
Raw Message
Patchset imported to github.
To create a pull request, one of the main developers has to initiate one via:
<https://github.com/systemd/systemd/compare/master...systemd-mailing-devs:6ea0792d-6e90-af6e-195e-ffb42f8a0e62%40smile.fr>

--
Generated by https://github.com/haraldh/mail2git
Mantas Mikulėnas
2017-11-29 12:06:25 UTC
Reply
Permalink
Raw Message
Post by Jérémy Rosen
I had a quick glance but didn't actually test...
1) please open a pull request on github, you will have more feedback that
way
I think it's supposed to be a patch for Weston on fd.o and only cc'd here
to systemd-devel...
--
Mantas Mikulėnas <***@gmail.com>
Pekka Paalanen
2017-11-29 13:34:23 UTC
Reply
Permalink
Raw Message
On Wed, 29 Nov 2017 14:06:25 +0200
Post by Mantas Mikulėnas
Post by Jérémy Rosen
I had a quick glance but didn't actually test...
1) please open a pull request on github, you will have more feedback that
way
I think it's supposed to be a patch for Weston on fd.o and only cc'd here
to systemd-devel...
Hi,

yes, it's a Weston patch, not a systemd patch. Sorry for the confusion,
I was just looking for feedback.


Thanks,
pq
Pekka Paalanen
2017-11-29 13:40:55 UTC
Reply
Permalink
Raw Message
On Wed, 29 Nov 2017 09:32:02 +0100
Post by Jérémy Rosen
I had a quick glance but didn't actually test...
2) you probably want to add Alias=display-manager.service, so it can
pull it other graphical services
Hi,

that sounds like a good idea.


Thanks,
pq

(adding back all the CCs)
Post by Jérémy Rosen
Post by Pekka Paalanen
There are many bad and even worse attempts to make Weston run as a
systemd service, and very few good ones. Let's add a good one as an
example in upstream: does not use weston-launch, does not run weston as
root, does not need wrapper scripts, and relies on logind and PAM.
This example has been composed from a couple of real-world Weston unit
files used in production. It has not been used verbatim, but it has been
briefly tested on one Yocto-based system.
The service file is not installed by the build. It would likely need
small adjustments for each distribution or system to be deplyed on.
The session-c1.scope workaround refers to a systemd bug that has been
said to be hard to reproduce, but the details have been lost in time.
Fixes: https://phabricator.freedesktop.org/T63
---
Hi all,
I have cross-posted this patch to systemd-devel with the hope that
someone would recall details about the systemd or PAM plugin race that
prompted the session-c1.scope workaround. I belive Martyn spoke about it
in person with Lennart, but as far as Martyn recalls, there is no record
of the issue. Enabling session lingering was mentioned as another
workaround.
---
doc/systemd/README | 45 +++++++++++++++++++++++++++++++
doc/systemd/weston.service | 66 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 111 insertions(+)
create mode 100644 doc/systemd/README
create mode 100644 doc/systemd/weston.service
diff --git a/doc/systemd/README b/doc/systemd/README
new file mode 100644
index 00000000..2aa3aa9a
--- /dev/null
+++ b/doc/systemd/README
@@ -0,0 +1,45 @@
+ Systemd integration examples
+
+These examples rely on Weston's logind and systemd support. Weston needs to be
+built with options: --enable-dbus --enable-systemd-login --enable-systemd-notify
+
+Furthermore, Weston needs to be configured to load systemd-notify.so plugin.
+
+$ weston --modules=systemd-notify.so
+
+
+[core]
+modules=systemd-notify.so
+
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+via systemd.
+
+
+ weston.service
+
+An example on how to run Weston as a system service. It starts a full user
+session of the named user on the given virtual terminal.
+
+This is useful for running a login manager or for dedicated systems that do not
+have personal user accounts and do not need the user to log in.
+
+You should very least customize the user, but likely also the tty and
+and the weston command line. See 'systemctl edit' command for an easy way to
+do that per-system if you don't edit the service file before installing it.
+
+This approach has an issue that in one system was worked around with the
+"After=session-c1.scope" directive. The details have been forgotten, but
+enabling session lingering was mentioned as another workaround. It might
+perhaps have something to do with multiple system units triggering the setup
+of a user session. It would be much better to start Weston as a systemd user
+service instead to avoid the issue completely.
+
+
+TODO: add an example of socket activation and defining sockets with systemd
+
+TODO: talk about starting Weston as a systemd user service, as that would
+often be more appropriate than as a system service. The user can still be
+automatically logged in. Presumably the auto-login service can allocate the VT.
diff --git a/doc/systemd/weston.service b/doc/systemd/weston.service
new file mode 100644
index 00000000..80d242a6
--- /dev/null
+++ b/doc/systemd/weston.service
@@ -0,0 +1,66 @@
+# This is a system unit for launching Weston with auto-login as the
+# user configured here.
+#
+# Weston must be built with systemd support, and your weston.ini must load
+# the plugin systemd-notify.so.
+
+[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
+
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+Before=graphical.target
+
+# Prevent starting on systems without virtual consoles, Weston requires one
+# for now.
+ConditionPathExists=/dev/tty0
+
+[Service]
+
+# Requires systemd-notify.so Weston plugin.
+Type=notify
+ExecStart=/usr/bin/weston
+
+# Optional watchdog setup
+TimeoutStartSec=60
+WatchdogSec=20
+
+# The user to run Weston as.
+User=westonuser
+
+# Set up a full user session for the user, required by Weston.
+PAMName=login
+
+# A virtual terminal is needed.
+TTYPath=/dev/tty7
+TTYReset=yes
+TTYVHangup=yes
+TTYVTDisallocate=yes
+
+# Fail to start if not controlling the tty.
+StandardInput=tty-fail
+
+# Log this user with utmp, letting it show up with commands 'w' and 'who'.
+UtmpIdentifier=tty7
+UtmpMode=user
+
+[install]
+WantedBy=graphical.target
Lennart Poettering
2017-11-29 18:05:07 UTC
Reply
Permalink
Raw Message
Post by Pekka Paalanen
+
+[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.
Post by Pekka Paalanen
+# 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.

Lennart
--
Lennart Poettering, Red Hat
Pekka Paalanen
2017-11-30 10:09:15 UTC
Reply
Permalink
Raw Message
On Wed, 29 Nov 2017 19:05:07 +0100
Post by Lennart Poettering
Post by Pekka Paalanen
+
+[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.
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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.
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
Martyn Welch
2017-11-30 11:16:19 UTC
Reply
Permalink
Raw Message
Post by Pekka Paalanen
On Wed, 29 Nov 2017 19:05:07 +0100
Post by Lennart Poettering
Post by Pekka Paalanen
+
+[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 ***@.service (IIRC this gets called as part of user
session creation, which I think was triggered by "User=xuser" in our
weston.service). The ***@.service has "PAMName=systemd-user" where as
weston.service has "PAMName=login". When ***@.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.
Post by Pekka Paalanen
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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
Post by Pekka Paalanen
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
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
Lennart Poettering
2017-11-30 12:32:46 UTC
Reply
Permalink
Raw Message
Post by Martyn Welch
Debugging suggested that XDG_RUNTIME_DIR was not being created when it
failed. There are 2 processes setting a PAMName, the failing Weston
session creation, which I think was triggered by "User=xuser" in our
everything worked as expected, if weston.service called PAM first it
failed. This was our attempt at forcing the former rather than the
latter.
Ah yeah, we discussed this recently here:

https://github.com/systemd/systemd/issues/7339

So the problem is that ***@.service currently can't be started
independently of logind, it must be logind that starts it for you at
the right moment. If you do anyway, XDG_RUNTIME_DIR won't be set, and
things fall apart. We should fix that though...

Lennart
--
Lennart Poettering, Red Hat
Pekka Paalanen
2017-12-01 11:42:52 UTC
Reply
Permalink
Raw Message
On Thu, 30 Nov 2017 11:16:19 +0000
Post by Martyn Welch
Post by Pekka Paalanen
On Wed, 29 Nov 2017 19:05:07 +0100
Post by Lennart Poettering
Post by Pekka Paalanen
+
+[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.
Post by Martyn Welch
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
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)
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
session creation, which I think was triggered by "User=xuser" in our
everything worked as expected, if weston.service called PAM first it
failed. This was our attempt at forcing the former rather than the
latter.
Post by Pekka Paalanen
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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
Lennart Poettering
2017-12-01 17:25:35 UTC
Reply
Permalink
Raw Message
Post by Pekka Paalanen
Post by Martyn Welch
Post by Pekka Paalanen
Post by Lennart Poettering
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
- 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.
Post by Pekka Paalanen
- 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/
Post by Pekka Paalanen
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...
Post by Pekka Paalanen
Post by Martyn Welch
Post by Pekka Paalanen
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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
Pekka Paalanen
2017-12-04 15:11:35 UTC
Reply
Permalink
Raw Message
On Fri, 1 Dec 2017 18:25:35 +0100
Post by Lennart Poettering
Post by Pekka Paalanen
Post by Martyn Welch
Post by Pekka Paalanen
Post by Lennart Poettering
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
- 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.
Weston doesn't set up the VT, we rely on the systemd unit directives to
set it up.

Weston calls sd_pid_get_session(getpid()), sd_session_get_seat(), and wants
sd_session_get_vt() to succeed and give a VT number. Then it connects
to logind, wants TakeControl to succeed, and calls Activate. It uses
TakeDevice to open the DRM KMS device and input devices. I think that's
the start-up sequence, it also listens on signals from logind etc.
Post by Lennart Poettering
Post by Pekka Paalanen
- access to DRM and input devices via logind
So, I can't comment on Weston really.
No worries, that was more of a general question about whether the
example unit file was making any unwarranted assumptions.
Post by Lennart Poettering
Here are brief (and possibly slightly out-of-date, but probably not)
https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/
Thanks, I had a quick read through. We expect the systemd unit to also
set up PAM, Weston itself does not touch PAM.
Post by Lennart Poettering
Post by Pekka Paalanen
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.
This is exactly what we attempted with the User and PAMName directive,
and it turned out to be racy somehow.
Post by Lennart Poettering
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...
Weston never was a --user service.

As far as I know, there was also nothing that would manually attempt to
start ***@.service, the only trigger for that were the User and PAMName
directives in the system weston.service.
Post by Lennart Poettering
Post by Pekka Paalanen
Post by Martyn Welch
Post by Pekka Paalanen
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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.
Yes, it was, but apparently somewhere in the PAM stack or something it
calls there was a race, which sometimes let Weston to start before
XDG_RUNTIME_DIR environment variable was set, causing weston to fail.

We all here were quite baffled on what could even be racing, unless it
is possible that the weston process gets started in parallel with the
PAM setup done by the User/PAMName in weston.service. We assumed that
all the setup described in the systemd unit file would be guaranteed to
complete before the actual process gets started.

It seems our and your expectations are aligned. Maybe we should just
forget about that race, remove the hacks that tried to work around it,
and see if anyone ever sees the failure again. Maybe it was something
very special on that one system alone.


Thanks,
pq
Matt Hoosier
2017-12-29 21:09:28 UTC
Reply
Permalink
Raw Message
Hi Lennart,
Post by Pekka Paalanen
On Fri, 1 Dec 2017 18:25:35 +0100
Post by Lennart Poettering
Post by Pekka Paalanen
Post by Martyn Welch
Post by Pekka Paalanen
Post by Lennart Poettering
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
- 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.
Weston doesn't set up the VT, we rely on the systemd unit directives to
set it up.
Weston calls sd_pid_get_session(getpid()), sd_session_get_seat(), and wants
sd_session_get_vt() to succeed and give a VT number. Then it connects
to logind, wants TakeControl to succeed, and calls Activate. It uses
TakeDevice to open the DRM KMS device and input devices. I think that's
the start-up sequence, it also listens on signals from logind etc.
Post by Lennart Poettering
Post by Pekka Paalanen
- access to DRM and input devices via logind
So, I can't comment on Weston really.
No worries, that was more of a general question about whether the
example unit file was making any unwarranted assumptions.
Post by Lennart Poettering
Here are brief (and possibly slightly out-of-date, but probably not)
https://www.freedesktop.org/wiki/Software/systemd/writing-display-managers/
Thanks, I had a quick read through. We expect the systemd unit to also
set up PAM, Weston itself does not touch PAM.
Post by Lennart Poettering
Post by Pekka Paalanen
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.
This is exactly what we attempted with the User and PAMName directive,
and it turned out to be racy somehow.
Post by Lennart Poettering
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...
Weston never was a --user service.
As far as I know, there was also nothing that would manually attempt to
directives in the system weston.service.
Post by Lennart Poettering
Post by Pekka Paalanen
Post by Martyn Welch
Post by Pekka Paalanen
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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.
Yes, it was, but apparently somewhere in the PAM stack or something it
calls there was a race, which sometimes let Weston to start before
XDG_RUNTIME_DIR environment variable was set, causing weston to fail.
We all here were quite baffled on what could even be racing, unless it
is possible that the weston process gets started in parallel with the
PAM setup done by the User/PAMName in weston.service. We assumed that
all the setup described in the systemd unit file would be guaranteed to
complete before the actual process gets started.
It seems our and your expectations are aligned. Maybe we should just
forget about that race, remove the hacks that tried to work around it,
and see if anyone ever sees the failure again. Maybe it was something
very special on that one system alone.
Thanks,
pq
The approach that you and Pekka most recently put on record here:

* User=foo
* PAMName=weston

with a /etc/pam.d/weston that just does minimal stuff (enforce the
account exists and then execute pam_systemd.so for the session phase)
works well for me.

One thing I can't figure out though: using PAMName= causes the service
process's journal entries emitted by regular stdout and stderr not to
be visible with 'journalctl -u weston.service' anymore. Only the
messages coming internally from systemd ("Started Weston." and
similar) show in that journal.

I've tacked in StandardOutput=journal and StandardError=journal to
compensate for the StandardInput=tty-fail. The messages do make it
across to journald; you can view them with 'journalctl
/usr/bin/weston'. But somehow they're not associated with the system
unit weston.service anymore. Does using the PAMName= directive cause
the stdout/stderr messages to be reassigned to a user-session unit or
something?

Thanks,
Matt
Mantas Mikulėnas
2017-12-29 21:32:00 UTC
Reply
Permalink
Raw Message
Post by Matt Hoosier
* User=foo
* PAMName=weston
with a /etc/pam.d/weston that just does minimal stuff (enforce the
account exists and then execute pam_systemd.so for the session phase)
works well for me.
One thing I can't figure out though: using PAMName= causes the service
process's journal entries emitted by regular stdout and stderr not to
be visible with 'journalctl -u weston.service' anymore. Only the
messages coming internally from systemd ("Started Weston." and
similar) show in that journal.
I've tacked in StandardOutput=journal and StandardError=journal to
compensate for the StandardInput=tty-fail. The messages do make it
across to journald; you can view them with 'journalctl
/usr/bin/weston'. But somehow they're not associated with the system
unit weston.service anymore. Does using the PAMName= directive cause
the stdout/stderr messages to be reassigned to a user-session unit or
something?
No, it's done by pam_systemd specifically.

The main purpose of pam_systemd is to create a user session and move the
process to the session's own cgroup (from the weston.service cgroup). As a
result systemd no longer considers it as belonging to the weston.service
unit, but to session-c123.scope or such.)

(The same happens with all other interactive login types -- e.g. when you
log in at the console, you get moved out of ***@.service and into your
own cgroup.)
--
Mantas Mikulėnas
Matt Hoosier
2017-12-29 21:39:05 UTC
Reply
Permalink
Raw Message
Post by Matt Hoosier
* User=foo
* PAMName=weston
with a /etc/pam.d/weston that just does minimal stuff (enforce the
account exists and then execute pam_systemd.so for the session phase)
works well for me.
One thing I can't figure out though: using PAMName= causes the service
process's journal entries emitted by regular stdout and stderr not to
be visible with 'journalctl -u weston.service' anymore. Only the
messages coming internally from systemd ("Started Weston." and
similar) show in that journal.
I've tacked in StandardOutput=journal and StandardError=journal to
compensate for the StandardInput=tty-fail. The messages do make it
across to journald; you can view them with 'journalctl
/usr/bin/weston'. But somehow they're not associated with the system
unit weston.service anymore. Does using the PAMName= directive cause
the stdout/stderr messages to be reassigned to a user-session unit or
something?
No, it's done by pam_systemd specifically.

The main purpose of pam_systemd is to create a user session and move the
process to the session's own cgroup (from the weston.service cgroup). As a
result systemd no longer considers it as belonging to the weston.service
unit, but to session-c123.scope or such.)

(The same happens with all other interactive login types -- e.g. when you
log in at the console, you get moved out of ***@.service and into your
own cgroup.)
--
Mantas Mikulėnas


Okay, thanks. So that's just hardwired behavior that we should expect? I
tried looking around the source to pam_systemd a bit, but quickly lost
track of the way that the 'type', 'class', and other parameters to logind's
CreateSession() eventually interact with systemd recordkeeping.

-Matt
Mantas Mikulėnas
2017-11-30 12:12:09 UTC
Reply
Permalink
Raw Message
Post by Pekka Paalanen
Post by Lennart Poettering
Post by Pekka Paalanen
+# 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.
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(?).
Instead of reusing "login", it would be better to start with a copy e.g.
lightdm's or xdm's config, IMHO.

There are three main steps in PAM. Besides "auth" (authentication, which
services simply skip), you also have "account" (authorization and
accounting) which verifies whether the user is allowed to log in – e.g. not
disabled, not locked out, not time-restricted. (For example, SSH pubkey
logins don't use PAM auth, but still have to perform the account
verification.)

Usually there's just one global configuration for "account" (e.g. in
pam.d/common-account) and you can directly include it.

But you also have "session" (session setup), which registers with
systemd-logind, sets up SELinux, prints the motd, and so on. These *do*
vary greatly between service types – e.g. you want pam_motd for 'login' but
not for 'cron'; you want pam_systemd for 'weston' but not for 'ftpd'. So
the "session" part may need to be customized, which is why you should start
with another graphical manager's.
Lennart Poettering
2017-11-30 12:29:22 UTC
Reply
Permalink
Raw Message
Post by Pekka Paalanen
Post by Lennart Poettering
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?
Oh, did we? I don't remember, sorry!
Post by Pekka Paalanen
Post by Lennart Poettering
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.
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?
Unfortunately PAM is awful and highly distro-specific. It's not really
possible to write PAM snippets that work generically on all
distros. Sorry. The distros even patch PAM differently, so that
slightly difference constructs are available...

Lennart
--
Lennart Poettering, Red Hat
Pekka Paalanen
2017-11-30 12:57:16 UTC
Reply
Permalink
Raw Message
On Thu, 30 Nov 2017 13:29:22 +0100
Post by Lennart Poettering
Post by Pekka Paalanen
Post by Lennart Poettering
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?
Oh, did we? I don't remember, sorry!
Hi Lennart,

no worries. I don't remember what I did early this week...
Post by Lennart Poettering
Post by Pekka Paalanen
Post by Lennart Poettering
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.
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?
Unfortunately PAM is awful and highly distro-specific. It's not really
possible to write PAM snippets that work generically on all
distros. Sorry. The distros even patch PAM differently, so that
slightly difference constructs are available...
That's the feeling I already got. Following Mantas' suggestion and
commenting it line by line like I did for the service unit is probably
the best we could do then.


Thanks,
pq
Loading...