On Sun, May 29, 2016 at 5:06 PM, Zbigniew Jędrzejewski-Szmek <zbyszek@xxxxxxxxx> 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx