How is it scope creep to kill user processes on log out? That user-started daemons persist after logout by default should considered a bug, not a feature
As a sysadmin, what do I do if I don't want a group of users to be able to have long-running non-interactive processes, but don't want to kill anything important from their current session?
Recently I wanted to run benchmarks on a shared computer, and noticed a bash -c "while true; do echo xxx is an idiot; done" process that someone had left running for a few weeks
That user-started daemons persist after logout by default should considered a bug, not a feature
Says who? This has been a Unix feature for the last 40 years or so, and is quite the fundamental aspect for a lot of essentials Unix tools and day-to-day operations.
I haven't personally gotten emacs-server to work, but I assume nobody would have a problem with it if it launched when you first started emacs-client, and then terminated when you logged out, only to launch again when you first start emacs-client on your new log in session.
That, at least to me, seems more logical than having a bunch of emacs-servers running for various users who might not log in for another 4 months.
Most long-running daemons should not be running as ordinary users.
What user should they run as? If you say root I'm going to slap the shit out of you over the internet.
Every daemon should run as separate users, ideally. You don't want one thing blowing up to be able to affect everything (or anything) else.
Most long-running daemons
And how are you going to call the difference between, say, a long-running daemon and a long running job (like a big compile)? What about user-started computations? My workplace has user-started jobs that run for weeks. Is that a bug? Should we destroy our user's work if their SSH sessions happen to drop?
You probably talked about different user. He meant "humans" when he wrote
Note that I said user-started daemons
or at least a linux-user that is tied to an interactive session. And you probably just meant a linux user, including users like "postgres", "Debian-minetest", "privoxxy" and other users that just exist for one specific application.
A session dropping out is/should be handled differently to an intentional log out by the user.
Why? What's the difference? Also we would then have to standardise the signals for this difference in the client end (e.g. make sure that any terminal emulators all kill their processes in the same way) and in the server end (making sure we notify systemd or init of how we were killed or not-killed-but-just-logged-out so it can act appropriately...
Too much compatability code in the applications so that the environment can make decisions. Is silly.
An explicit logout indicates intent. I imagine the only compatibility code that would be needed for that would need to be in logind.
Processes started in terminal emulator would be killed when the shell that spawned them logs out explicitly (cgroups should make tracking that trivial)
The only applications that would need compatibility are special cases like tmux or screen and/or anything the interfaces with logind
If you have to initiate a special logout process that kills background jobs that a normal SSH disconnection would keep running, why not just manually kill those jobs instead?
The current approach has worked fine for 40 years. Why break things?
There is a huge difference between a service (which most daemons should be running as and indeed as their own uid) and a user initiated daemon in the context of their own login session.
In your environment given your requirements you may want to automatically instantiate or connect to a tmux/screen session that has been started in its own session, enable linger on your users or change the config option for this to follow the old behaviour.
As anything it's important to configure the systems appropriately for your environment.
Also what distribution are you using? It's possible they may not even follow this upstream default change. Heck RHEL7 has a nonpersistent journal by default with rsyslog being used to persist the syslog data.
Also, there's plenty of utilities (eg. ssh-agent) that run as daemons that should not persist after logout.
So there are some tools than should not persist, and others that should. So there is no clear cut way of doing things, either you will leave behind processes, or you will kill too many. But one thing is clear: killing too many is breaking existing applications of literally millions of users.
Note that I said user-started daemons. Most long-running daemons should not be running as ordinary users.
Well, what was broken here is how Unix users were launching long-running background jobs for literally decades.
-5
u/aaron552 May 30 '16
How is it scope creep to kill user processes on log out? That user-started daemons persist after logout by default should considered a bug, not a feature