On Wed, Aug 31, 2016 at 10:25 AM, Jason L Tibbitts III <tibbs@xxxxxxxxxxx> wrote: > After reading (some of) the "discussion" about systemd-logind's > 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 will > 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 manager > 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 > particularly unreasonable. 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 that > 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 > discussion. 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. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
