On 27.05.2016 15:57, Lennart Poettering wrote:
On Fri, 27.05.16 08:09, Chris Adams (linux(a)cmadams.net) wrote:
> Once upon a time, Zbigniew Jędrzejewski-Szmek <zbyszek(a)in.waw.pl> said:
>> Also note that running jobs in a systemd service has advantages on the
>> server: better accounting, more transparency, logs are easier to read.
>> The (old) default of allowing left-over session processes to live on
>> seems especially bad on a server with multiple users.
> Starting a one-off task under screen and detaching is an age-old server
> management process. Breaking that is not acceptable IMHO.
And it is still supported.
In my view it was actually quite strange of UNIX that it by default
let arbitrary user code stay around unrestricted after logout. It has
been discussed for ages now among many OS people, that this should
possible but certainly not be the default, but nobody dared so far to
flip the switch to turn it from a default to an option. Not cleaning
up user sessions after logout is not only ugly and somewhat hackish
but also a security problem.
systemd 230 now finally flipped the switch and finally by default
cleans everything up correctly when the user logs out. But we do so in
a very conservative way actually:
a) there's a compile time switch to turn this off globally
(--without-kill-user-processes, not used in Fedora)
b) there's a runtime switch to turn this off locally on the system
c) there's a way to opt-out invidually for each user and each task
from the cleanup logic, via systemd-run/loginctl linger. This
operation goes through PK, and thus can be configured in a more
strict or more open policy, depending on whhat the admin prefers.
Would it make sense to add a extended file attribute that allows systemd
to query if an application should be killed or not? screen and tmux
could have those added as long as they don't talk to systemd.
Either this extended attribute could be checked lazily or the elf
process loader could inform systemd about the new requested scope.
Has this been looked at?