Re: systemd 230 change - KillUserProcesses defaults to yes

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, May 29, 2016 at 12:53:26PM -0600, Kevin Fenzi wrote:
> So, my 2 cents... 
> 
> Some questions for upstream: 
> 
> * I assume killed processes are logged in the journal, but Is there
>   any way to have a 'permissive' version? ie, simply log what would
>   have been killed, but not do anything? That would be very helpful to
>   folks to identify things that would be affected here without
>   disrupting them at first. It would also allow bugs in other packages
>   to get fixed up. 

No, the killed processes are not logged, even at debug level, afaik.
PID1 simply loops over the control cgroup and sends signals.

I see how having a 'permissive' option could be useful.

> * 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).

> * How can I tell if linger is enabled or disabled on a user?
loginctl user-status <user>
or
loginctl show-user -p Linger <user>

> * enable-linger/disable-linger need root? So, the only way the user can
>   exclude things is to use systemd-run?
It is controlled through polkit. There are two operations:
org.freedesktop.login1.set-user-linger which by default requires admin privileges,
and
org.freedesktop.login1.set-self-linger which by default allow any user
to enable lingering for themselves.
So lingering (with the default policy) requires no privileges, just
an explicit enabling.

> For the Fedora side:
> 
> I agree that it should be a F25 change so things can be coordinated and
> so it has higher visibility for users. This would also allow time/a
> chance for working groups to decide if they want to have a per edition
> default that's different from the base one. 
> 
> If something like a 'permissive' mode is possible, I would think it
> would be nice to move rawhide to that for now, if not, I don't feel too
> strongly either way on leaving it enabled for now. (On one hand
> disruption for users, on the other hand rawhide users should all be
> subscribed to this list and can change the default if they wish). 
> 
> If we can handle the common cases, I think this is a lovely step
> forward. 

Zbyszek
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux