>>>>> "NK" == Nico Kadel-Garcia <nkadel@xxxxxxxxx> writes: NK> To me, it looks like systemd is activating a universal policy which NK> you, and others, need more thoughtful and tunable handling for. NK> Attempting to tune it by outsmarting systemd's default behavior NK> looks expensive and unstable. Well, please keep in mind that _I_ am the one who is activating this. I don't care one way or the other what the default is; a single line in a file in /etc/systemd/logind.conf.d sets that the way I like. NK> Agreed. The acceptance of the feature without any logging, NK> whatsoever, of what processes it killed and when shocked me. I'm not talking about any feature or any acceptance. This is entirely something I am trying, on my own, because I was intrigued by the possibility of enforced process death at session termination. I am making no commentary on the viability of any of this for Fedora in general. I'm just sharing my experiences. Perhaps others can glean something useful from them in some relation to what Fedora may or may not do in the future, and that's fine, but I'm not trying to influence that in any way. >> 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. NK> Wouldn't an hourly or nightly cron job reporting such tasks, with an NK> option to kill them on a group or user based policy basis, be safer NK> if such a daemon is needed? I'm not entirely sure what you're suggesting. If you're saying that I could just a cron job cleaning up jobs that shouldn't be there, I am not certain that such a thing is possible. Plus I've experienced a problem where users get dropped back to the login box after a timeout, with their session destroyed but processes still hanging around in such a way that they're prevented from logging in a second time. Hourly cleanup of these things is far too slow, and sub-minute-ly would be kind of a waste. KillUserProcesses=yes appears to handle this case just fine as far as I've been able to test this. (It's tough to reproduce, and does involve the confluence of other bugs.) NK> Can the tasks run with cron jobs in your environment? I realize that NK> Kerberized access to user home directories might prevent working NK> access to scripts that live in their home directory. Well, teaching users to do that would be beyond my means. (I'm only human, after all.) Something like Condor is a far better option for using desktop cycles in the background, but it's tough to beat the "nohup my_job" that they learned out of some book about Fortran 25 years ago. NK> The thoughtful hands-on experience is welcome. It confirms the idea NK> that in multi-user environment, backgrounded sessions continuing NK> after logout is a common and effectively used feature worthy of NK> support. Well, keep in mind that it will always be supported as long as you can still set KillUserProcesses=no. I'm trying to get the best of both worlds, to the extent that is possible, and I'm willing to hack things to get it. I'm not asking anyone else to support that, but I am trying to inform them of what they're up against should they want the same thing. I do have a suspicion that I'm not the only person who would want this, though, which is why I sent the message in the first place. - J< -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
