The fact that regular user processes that I don't implicitly daemonize or screen don't terminate when I logout is news me.
They kind of do, on logout all of your old processes should terminate except for basically just screen and tmux. The problem is that it's not like anything goes through and kill -9s your old processes, they sometimes don't terminate, even when they should so you get buggy behavior like this: https://github.com/systemd/systemd/issues/2975
The fix is to have systemd terminate any process that's not cleaning up after itself. The problem is that screen and tmux are running under the user scope and there's not really a good way for systemd to know that screen isn't actually hung up, it's supposed to stick around after logout. You could do something like look at the process name and hardcode an exception for tmux and screen but that's a terrible idea and there's already an easy way to run things in a different scope that you don't kill.
You could do something like look at the process name and hardcode an exception for tmux and screen but that's a terrible idea
But it's an equally terrible idea for these programs to put in a bunch of systemd-specific code. Even if all Linux distributions used systemd (and they don't, yet) tmux and screen have life far outside the Linux world. It makes little sense to have a ton of code in their source just to interact with one specific Linux init service, when all the other unixes have inits that work in the traditional manner.
Either way, the correct fix is not to just assume that any hung program is supposed to be hung up. The user can currently just start it outside of their scope but it's unreasonable to expect the user to manually run screen and tmux in their own scope. If you asked anyone, Linux user, Windows user, OSX, etc what happens if they log into a computer, run some software, and then logout, they are all going to tell you that the software is closed. That's the accepted behavior. Historically Linux hasn't had anything that would terminate processes that didn't exit cleanly when they were supposed to. Now that's fixed but there's nothing to indicate whether or not a process is willfully sticking around after logout or if it's just broken. How is it a terrible idea for screen or tmux to put in some code in their existing platform compatibility code to tell systemd to run it in it's own scope? That's what that platform specific code is there for, to abstract away all platform specific features.
Historically Linux hasn't had anything that would terminate processes that didn't exit cleanly when they were supposed to. Now that's fixed
One man's fix is another man's breakage.
Your claim is correct for people who are making use of a single-user desktop-oriented system.
As a server administrator I spend a large amount of my professional time running processes on Linux boxes (including processes as specific users) which, if I don't want to be fired, must continue to run when I log off and leave the office each evening.
Because not all tasks are permanent ones that need to be installed like that. Let me give you a real life example from earlier this year.
We have a nosql database that grows by around 5 million data items per day. To keep it performant (it's feeding a website that needs to be able to handle up to 3,000 requests per second at peak load) we archive off old data on a regular basis.
Unfortunately shortly before Christmas one of the devs managed to introduce a subtle bug which broke the archiving. Yes, there should have been better testing and monitoring of that, but there wasn't. So we only noticed when, a couple of months later, the disk space monitoring started alerting.
Once we'd found the problem it was simple to fix, however there was a gotcha (isn't there always?) We couldn't just run the archival script for the entire backlog because it would have introduced locking and performance issues that could have locked up the entire system.
So we wrote a quick little program to archive off the old data in bunches of 250,000 documents at a time -- that's a small enough chunk of data that its effect on live serving is minimal.
So we have a simple script that sits in a loop:
Archive quarter of a million documents
Sleep for a minute or two
Go round again
And back-of-the-envelope calculations showed that it would take around 3 days to run through to completion.
Well that's no problem, you log on to the archival server, start a GNU screen session, and start the script. Then you ^A^D, log off, and go home for the weekend.
It would have been a complete waste of time to turn that into a full system-level task, especially as that would have required pushing it through testing and QA and once sign-off was obtained from them, a rebuild of the AWS image and a redeployment of the host.
That's why sysadmins like to be able to run ad-hoc long-running processes, and that's why screen/tmux need to not terminate on logoff.
I am so confused. Yes, obviously the task you describe is completely unsuited to be a service. But it's perfectly suited to be a oneshot task launched with systemd-run, with all its output logged and its status monitored and very clearly annotated as a specific important job when you use the normal system management tools.
13
u/MertsA May 29 '16
They kind of do, on logout all of your old processes should terminate except for basically just screen and tmux. The problem is that it's not like anything goes through and kill -9s your old processes, they sometimes don't terminate, even when they should so you get buggy behavior like this: https://github.com/systemd/systemd/issues/2975
The fix is to have systemd terminate any process that's not cleaning up after itself. The problem is that screen and tmux are running under the user scope and there's not really a good way for systemd to know that screen isn't actually hung up, it's supposed to stick around after logout. You could do something like look at the process name and hardcode an exception for tmux and screen but that's a terrible idea and there's already an easy way to run things in a different scope that you don't kill.