2017-11-28 10:14:29 UTC
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.
Signed-off-by: Pekka Paalanen <***@collabora.co.uk>
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
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
@@ -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:
+The plugin implements the systemd service notification protocol, watchdog
+protocol, and also allows socket activation and configuring listening sockets
+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
@@ -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.
+Description=Weston, a Wayland compositor, as a system service
+# Make sure we are started after logins are permitted.
+# If Plymouth is used, we want to start when it is on its way out.
+# D-Bus is necessary for contacting logind. Logind is required.
+# 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.
+# Since we are part of the graphical session, make sure we are started before
+# it is complete.
+# Prevent starting on systems without virtual consoles, Weston requires one
+# for now.
+# Requires systemd-notify.so Weston plugin.
+# Optional watchdog setup
+# The user to run Weston as.
+# Set up a full user session for the user, required by Weston.
+# A virtual terminal is needed.
+# Fail to start if not controlling the tty.
+# Log this user with utmp, letting it show up with commands 'w' and 'who'.