Re: per-user instanced system services vs systemd user services
On Mon, 09 Nov 2020 at 09:25:25 +0900, Norbert Preining wrote:
> Onedrive ships
> /lib/systemd/system/onedrive@.service
> and for example on my system root has started
> onedrive@norbert
> service (this is better than an actual user starting, since systemd
> tears down the service after log out, which I don't want).
As said elsewhere in the thread, this is an instanced system service
that happens to have a username as its instance identifier (but systemd
doesn't know that, because instance identifiers are opaque to everyone
except the service and the sysadmin). I've said more about how to manage
instanced systemd services elsewhere in the thread, which hopefully answers
your original question.
A major disadvantage of this is that users cannot manage their own onedrive
services: if the onedrive service runs as their own uid, then maybe they
can send POSIX signals to it, but they cannot use `systemctl --user restart`
to restart it, or use `systemctl --user edit` to alter its launch parameters,
or use `systemctl --user disable` to stop it from running. Only the sysadmin
can control whether and how onedrive runs on their behalf.
When you say "an actual user starting", a systemd user service managed
by `systemd --user` would be an example of this. This is how
`dbus-daemon --session`, pulseaudio, gpg-agent, gvfs-daemon, Tracker
and various other per-user services are managed on systemd systems, and
is increasingly used by GUI environments like KDE and GNOME to manage
desktop components.
If you would like the onedrive service for a particular uid to persist,
*without* having to move it to system level, there are a few ways you can
achieve that. Choose one:
* Enable "lingering" for the user: `loginctl enable-linger norbert`.
This will run user@${uid}.service on system boot, and not shut it
down until system shutdown. Any user service that is enabled in
default.target will start on boot and not be killed until shutdown.
* Or, make sure the user's processes are not killed when the user logs out,
and then make sure at least one process from the user's login session
continues to run in the "abandoned scope" even after logout. Killing
processes is controlled by KillUserProcesses, KillOnlyUsers,
KillExcludeUsers in logind.conf(5). The upstream default is
KillUserProcesses=yes, but Debian overrides it to KillUserProcesses=no.
* Or, have a PAM stack that includes pam_systemd.so, and a system service
that "logs in" with that PAM stack for the duration of the time in which
you want background services like onedrive to persist.
smcv
Reply to: