On Wed, Aug 31, 2016 at 10:25 AM, Jason L Tibbitts III
After reading (some of) the "discussion" about
KillUserProcesses setting, I decided that I'd like to try enabling it
and see how it works and how I can make it useful in my environment.
Sorry, it's long, but I though folks might want to know.
Thanks for the thoughtful work.
Now at each boot, no users are set to linger and no user managers
be started until login. The wrapper scripts will re-enable that as
necessary so this doesn't hurt anything.
Wrapper scripts. *Yech*.
To me, it looks like systemd is activating a universal policy which
you, and others, need more thoughtful and tunable handling for.
Attempting to tune it by outsmarting systemd's default behavior looks
expensive and unstable.
Conclusion: I can make this work, mostly, unless someones user
happens to die. But really, this is all an unpleasant hack,
necessitated by a mismatch between systemd's design and what I'm trying
to accomplish. And I don't think that what I'm trying to accomplish is
Agreed. The acceptance of the feature without any logging, whatsoever,
of what processes it killed and when shocked me. It's the sort of
breakage of working, stable tools in the name of "resource management"
that gets people fired..
What I wish for is for some "property", let's call it
"persist" to be
"attached" to a scope in some way (presumably a flag to systemd-run)
which does nothing other than to indicate that the scope will continue
to run after the user's session has terminated. This wouldn't be a
persistent user setting. Nothing would start at boot. The user manager
would start up if necessary at login (even if it had previously been
killed) and persist until all user processes in any scope have exited.
Wouldn't an hourly or nightly cron job reporting such tasks, with an
option to kill them on a group or user based policy basis, be safer if
such a daemon is needed?
I am perfectly happy with wrappers around programs which indicate
something is to persist after logins so my users don't have to learn
systemd-run. I don't think systemd itself needs to know or care which
processes should persist. I don't care if those wrappers are in the
base system. If things like nohup or screen are patched to do this
automatically, I'm happy with that but it makes no difference to me.
Can the tasks run with cron jobs in your environment? I realize that
Kerberized access to user home directories might prevent working
access to scripts that live in their home directory.
Hope this is interesting to someone and adds useful content to the
The thoughtful hands-on experience is welcome. It confirms the idea
that in multi-user environment, backgrounded sessions continuing after
logout is a common and effectively used feature worthy of support.