I mean that is their position yes. It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.” This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out.

This is a feature that sysadmins have been asking for. On any multi-user system you run into this crap where background processes for users who are long-since gone just hang around forever because they do weird things or hang and ignored the signal. We implemented it ourselves with PAM but systemd’s solution is a lot cleaner.

And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.

> it’s weird that “logging out” doesn’t imply “and end all my programs.”

Weirdness is in the eye of the beholder. I regularly run programs whose lifecycles are not in sync with my login session. Why do I need to stick around to see a batch job complete?

I can understand that different folks have different backgrounds which changes expectations... but come on... somebody bringing up tmux, screen, etc. should simply end the conversation. "Oh, that is a common and historical use case that I have not considered, today I learned something."

>> it’s weird that “logging out” doesn’t imply “and end all my programs.”

> Weirdness is in the eye of the beholder

It's a windows acolyte mindset. Many people don't imagine that a login is just another program, rather than the parent process.

Yes but that model conflicts with the human notion of being “logged in” to a system.

And the current behavior is literally what you describe. It’s just the quirk of subreapers being implemented recently that daemonizing a process wasn’t local to your session.

It makes zero sense that a process that double forks is reparented by init instead of your session leader. If how things worked currently was proposed today it would sound crazy.

>It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.”

I have to disagree, I don't think I've ever run something where what I intend is "kill this mid-run if my connection drops".

>This is basically the same behavior as Windows

My recollection from when I used Windows Server (admittedly some time ago) is that the default behavior on connection loss or closing an RDP window is indeed the tmux-like behavior. The user has to click a separate "Log out" button, and even then, has to manually confirm that it's okay to kill anything left running.

> It’s a good default too since it’s weird that “logging out” doesn’t imply “and end all my programs.”

It may be a good default if you're starting from scratch, but GNU Screen has came out in 1987. (Poettering was 7 years old then.)

> This is basically the same behavior as Windows […]

Comparing it to Windows' behaviour is not going to win you any positive points with me. :)

> This is a feature that sysadmins have been asking for.

As a sysadmin this breaks my own daily workflow. I have 400 VMs that are treated as pets and I probably screen sessions on at least a third of them. (I have another 500 that are cattle-like.)

> And they’re not breaking any POSIX behavior. Nowhere does it say when the system isn’t allowed to kill a process.

Aka, malicious compliance. See also: nowhere does it say that the US President cannot fire the FBI Director. Also: nowhere does it say that the US Senate has to hold hearings when a US President nominates a judge for the US Supreme Court.

> This is basically the same behavior as Windows where anything not going through the task scheduler ends when you log out.

But when using remote connections, ie RDP, the default is that your session is disconnected. You have to actively choose to log out of an RDP session.

When using SSH I typically want the same. If I put my laptop to sleep or a networking issue causes the TCP connection to end, I want my terminal session to be restored when I reconnect via SSH.

”ain't no rule says a dog can't play basketball”