However, if you login to a graphical desktop, that is not a text terminal, and therefore everything is effectively nohup'd: your browser, your chat program, your media player, all the miscellaneous helper processes they spawn, etc. Most people do want that stuff to be automatically shut down when they log out.
Since the kernel's idea of "a login session" is wrong (it only includes text-terminals), and it can't easily be changed for compatibility reasons, systemd implements its own idea of "a login session" that works the way most people (who aren't experts on POSIX job control) expect.
Systemd's revamped notion of "session" includes graphical ones. Yes, that's different from the legacy sense of a mere text-terminal window. But since they've had to reimplement the whole concept of graphical sessions anyway, they could have made them work like textual ones. If you're not running a session manager as part of your windowed environment (almost everyone is these days) the whole thing might break, but then you can just enable the hacky "lingering" mode to make it work and you're no worse off than before.
This is a CADT attitude. Improving existing interfaces while maintaining compatibility is hard; it's also what makes the difference between a serious software professional and an incompetent vandal.
The fact that the logind developers came to a different solution than you, after spending much more time thinking about it and actually implemented it, doesn't exactly imply logind developers are the ones with an attention deficit, or that logind is bad. ("CADT" apparently means "Cascade of Attention-Deficit Teenagers")
Also, never call out others as "incompetent vandals" if you think of yourself as a "serious software professional". This is the kind of toxic behavior that makes communities non-inclusive and leads to impostor syndrome.
The logind developers went against the established wisdom of experience (that big rewrites are generally a bad idea) with the predictable result: high costs (both in migration and in handling outright bugs) for nebulous benefits, with the result that desktop linux is flakier and (understandably) less popular than ten years ago.
> This is the kind of toxic behavior that makes communities non-inclusive and leads to impostor syndrome.
Is that supposed to be a bad thing? We should be less "inclusive" of people who want to rewrite everything. They should feel like impostors. You can't produce good quality if you're not willing to call out bad quality; Linux succeeded (for a time) because Torvalds had high standards and was willing to maintain them.
I want to exclude incompetent vandals from the software community; they are impostors.
Some people consistently make bad decisions. Some of them can change, but others cannot. I do not want the ones who cannot or do not learn to make good decisions to make decisions which affect me (I acknowledge that I myself may be one of those people!).
Quality matters. Reckless vandalism matters too. Breaking nohup was and is indefensible.
No, it's not.
I think you're looking at this in the wrong way. The concept here is one of sessions and the parent-child relationship between them, as well as the decisions parent processes make when they create and manage (or don't manage) child processes.
If you log in to a text console, you end up with a process (like bash) controlling the terminal. If you run normal programs in the foreground, or even in the background (as long as you don't disconnect them from the controlling terminal), they are all children of that bash process. When you quit bash, all its children get terminated as well.
When you log into a graphical session, the login manager (or whatever) will start your desktop's session (which might just be a plain shell script, maybe just your window manager, or might be a full-blown session manager, or something else entirely). Whatever that is, it starts other applications (say your window manager, a panel or dock, desktop manager, etc.), which then can start other applications (browser, chat, media player). If you log out of your desktop, ultimately what happens is that original session-starter (script, WM, session manager, whatever) quits, and it takes all its children with it.
And regardless, the graphical session still runs in a TTY, just not in text mode!
> Since the kernel's idea of "a login session" is wrong
The kernel has no concept of login sessions at all (it does have the concept of "sessions", but they are unrelated to user login). It just starts something as root (init, as PID 1), and from there userspace takes over and does whatever it wants, including the possibility of starting a getty, which can run login, which can setuid() and launch your shell if you put in the right password. (Or run a display manager that does something analogous with graphical sessions.)
So back to the beginning:
> The trouble is that 'nohup' is not a particular state that specifically marks processes that want to survive logout. Instead, the rule is that processes running inside a particular terminal are killed when that terminal closes, and processes running outside any terminal run as they please.
Those two sentences would seem to be contradictory, no? "nohup" is of course not a particular state, though it is responsible for putting a process into a particular state: that of not having a controlling TTY. Which is (greatly simplified) what determines whether or not a process keeps running once the TTY's controlling process exits.
> When you log into a graphical session, the login manager (or whatever) will start your desktop's session (which might just be a plain shell script, maybe just your window manager, or might be a full-blown session manager, or something else entirely). Whatever that is, it starts other applications (say your window manager, a panel or dock, desktop manager, etc.), which then can start other applications (browser, chat, media player). If you log out of your desktop, ultimately what happens is that original session-starter (script, WM, session manager, whatever) quits, and it takes all its children with it.
This isn't how it works though: killing a parent does not kill its child, which is probably one of the bigger design flaws in the original unix (and probably persists because through another design flaw it's the only way to reparent processes, as the insane double-fork 'daemonisation' routine demonstrates). This is one of the things systemd aims to fix: by keeping track of process relationships with cgroups it can kill all the of the processes spawned in a session.
And I'm not sure about your assertion about graphical sessions: pretty much all processes on my PC have no controlling terminal.
Now what happens if it crashes? Repeatedly? Or if a user intentionally manipulates their session to keep running?
Should any user on a shared university computer be able to spawn processes to run for all eternity?
Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow?
That's for the university IT to decide, of course. Software should focus on providing general mechanism, not policy.
> Should your desktop environment crashing lead to all software continuing to run, for all eternity, leaking memory like there’s no tomorrow?
AIUI, that's pretty much what might happen if you're forced to enable the lingering option to make nohup work. Systemd does improve session management under *ix-like systems, but the fact that it doesn't manage to interoperate cleanly with the likes of tmux and screen is a pretty blatant papercut.
