On Sun, May 29, 2016 at 5:06 PM, Zbigniew Jędrzejewski-Szmek
<zbyszek(a)in.waw.pl> wrote:
> * Does 'loginctl enable-linger <user>' take effect
in the current
> session? Or do you have to start a new one? does it persist over
> sessions or only affects the current/next one?
Lingering applies to the systemd --user instance, a.k.a. systemd@.service,
not to the session. Lingering means that systemd@.service is present
even if you are not logged in. If lingering is disabled, it is started
on login, and stopped on logout of that user.
Killing processes which are part of the session (session-<n>.scope)
doesn't have anything to do directly with lingering. It is controlled by
the global KillUserProcesses= setting.
The connection between KillUserProcesses= and long-running processes is
that if KillUserProcesses=yes is set (the new default), to successfully
create a process which survives logout two steps are needed:
1. move it out of the session into a systemd --user unit,
2. make that systemd --user instance persistent, i.e. enable lingering.
Setting lingering is done over dbus, takes effect immediately, and is
persistent (/var/lib/systemd/linger/<user> is created).
Setting KillUserProcesses can be done by modifying /etc/systemd/logind.conf,
and also takes effect immediately, if systemd-logind is reloaded
(using SIGHUP).
Can you clarify how systemd-run --user --scope fits in to this?
While I certainly understand the motivation of running services in a
clean environment (as systemd-run without --scope would do), there are
cases where that's the wrong thing to do. For example, if nohup were
adjusted to work in the new regime, it would *not* want a clean
environment. But I still don't understand how scopes work, what they
have to do with lingering, whether every scope lives strictly within a
service, or pretty much anything else about them. The
systemd.scope(5) manpage isn't particularly helpful.
--Andy