Having user processes killed upon log out seems pretty reasonable to me, and its a configurable option if you don't like it. I don't get the fuss here.
I think it's just popular to dislike systemd, some sort of echo chamber effect or something.
Default Debian Trixie out of the box configuration without changing any systemd config file allows gnu screen to work as it always has. There would have been great uproar and screeching if basic 'screen' detach and resume functionality had broken anywhere between Debian v11, v12 and v13, and it has not.
I'm assuming this is same for tmux but hasn't tested it.
Is there some major distro out there that has the config flag set the opposite of this by default?
I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which - while well documented - suffers from sprawl & overwhelm of the docs. There's just SO MUCH to grok in comparison.
Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.
I'm still using sysvinit without anything on top (the default would have been sysvinit + openrc, but I dropped openrc, too complicated for my needs). I find it a lot easier than learning systemd, or learning anything else. To find out what's going on, I just need to open one file: /etc/inittab, and it's all in there. Nothing hidden somewhere else. Nothing undocumented. Simple commands, one after another. There are no dependencies, no conditions, not unless I put them there myself.
So, I disagree about your statement here, but let's for a moment assume it were
correct - so let's not evaluate THAT particular statement, thus.
You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?
Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write - pretty much all logic in ruby and .yml files. Literally my whole system is described via .yml files, ruby then just auto-expands all of this into what is meaningful. I also compile from source and manage the system via ruby as-is, so I don't even need systemd, nor shell scripts. But this is just one comment here and if you refer to shell scripts then I agree with you - shell scripts have always been horrible. I fail to see why we should like systemd merely because shell scripts are so awful. That makes no sense. I neither use systemd nor shell scripts (ok ok I bail ... I am currently using manjaro which uses systemd; I disabled most of the services, but the primary reason I was assimilated into systemd is mostly because the non-systemd linux distributions, kind of gave up for the most part or come with their own set of problems - slackware, void and so forth. And yeah, I was using and testing them for ages too, slackware I used for many, many years. It is still a great distribution but it is not really active anymore. No new .iso releases in years, sorry, that is dead. Even if Patrick still updates packages.)
The other part is ... IF you referred to an alternative init system, then THAT comparison is flawed too, because sysvinit is mostly just an init system. Systemd is some giant thing that does 100000 things. So the comparison is, and ALWAYS has been, unfair. Not the same things are compared here.
Well, in my experience, systemd has much worse documentation, is very inconsistent (or you could say it is constistantly brain-dead), and extremely unreliable and unpredictable, since it often hangs when shutting down and rebooting.
> Things not working the way I expect means I have to do more work to figure something out.
I dunno, "things not working the way I expect" is very subjective.
I personally think it makes more sense that processes do not outlive the parent from which they come (in this case processes spawned from a user shouldn't outlive that user) unless you explicitly go through something which outlive the parent (process manager in this case (e.g. running via systemd-run)).
Though I am also strongly of the opinion of just because something is a feature, does not mean it is good to keep around, e.g SUID/SGID (which has a similar "I get more than the parent" problem).
Though I guess different people can have different opinions/values on this.
It's one of those systemd features that are annoying and in the way when you're trying to accomplish a specific task but deal well with shitware. To be fair to systemd, these features can't usually be implemented without writing new rules for what you have to do to accomplish the legitimate tasks.
Yes. Improvement or not, a thing not working the way one expects means one has to do more work to figure something out. And in case of pid1, this is never a time spent productively.
I'm all for improvements and I love updates of software, but what systemd usually does is ideology and destruction in the name of "new". Like, we have had cron perfectly working for _decades_ until one man told us we were all wrong on that.
> One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too.
Killing processes that the user clearly did not want killed is a regression.
Reading the rest of article it seems that its fixed but made things a lot more complicated than "unless you deliberately start things so that they keep running when you logout they will be killed when you logout". Am I wrong?
"The way you expect" is probably inconsistent and, upon closer inspection, completely broken.
There is a reason why systemd became the default and other niche init systems have faded into obscurity.
Sure, it may be more complex than your pile of shell scripts, but that's because it does the same things better, and has a lot more functionality that you will need at some point, and good luck replicating that by hacking shell scripts.
I, for one, appreciate the honesty. I wish more systemd haters would admit this is why they dislike it. We could finally throw away the tired arguments that have been disproven in the past ten years
> We could finally throw away the tired arguments that have been disproven in the past ten years ...
Here's one you cannot disprove: the Jian Tan XZ backdoor did not affect Linux distro that weren't using systemd.
I know, I know, it's got absolutely nothing to do with systemd.
We're talking about something insane like upstream OpenSSH being modified to add systemd logs "log compression" to freaking OpenSSH (yay security, makes perfect sense!).
So disprove this: not a single Linux systemd-less distro was affected by an attempt to place a worldwide backdoor on Linux systems exposing a SSH port.
P.S: I moved all my infra to VMs that are systemd-free and containers, by default, do not run systemd as PID 1 (they don't run it at all). It works flawlessly. I'll now move my hypervisors to FreeBSD+bhyve and I'll be, at long last, totally systemd-free again (I was using Linux before "systemd-I-compress-logs-so-I-make-you-modify-OpenSSH-to-add-liblzma-dependency" came on the scene with it's its Windows-style .INI files and these were much better days).
I'm presumably missing something here. Why does tmux et al not work? Remotely? Ie you're logged in locally and remotely to the same machine, log out locally which kills everything running remotely, but then why would you log in twice like that?
And that being the case can systemd not just only close everything when your logins reach 0?
I never had a problem with systemd init despite its quirky habits like just giving up if a mount is bad in fstab, and I rather like systemd-networkd over the other four or five ways of managing the network. Systemd-timesyncd isn’t bad either.
But this, systemd-logind worrying about stuck processes in userspace is exactly the kind of scope creep that ends up justifying a lot of the hand wringing a decade ago. This thing bit me when it came out in a couple different ways and I am unapologetic in my dislike for it. So much so that it has caused me to drift away from Linux where I can. Even though it is a simple fix, I’ve become fatigued with userspace chaos.
Time to re-evaluate what the bazaar has become. Systemd is a common complaint, but it isn’t the only contributor to the fatigue.
Having user processes killed upon log out seems pretty reasonable to me, and its a configurable option if you don't like it. I don't get the fuss here.
I think it's just popular to dislike systemd, some sort of echo chamber effect or something.
Default Debian Trixie out of the box configuration without changing any systemd config file allows gnu screen to work as it always has. There would have been great uproar and screeching if basic 'screen' detach and resume functionality had broken anywhere between Debian v11, v12 and v13, and it has not.
I'm assuming this is same for tmux but hasn't tested it.
Is there some major distro out there that has the config flag set the opposite of this by default?
> Default Debian Trixie out of the box configuration without changing any systemd config file allows gnu screen to work as it always has.
As mentioned in the second sentence of TFA. Debian enables linger by default.
> Is there some major distro out there that has the config flag set the opposite of this by default?
It bit me on pop os (the Ubuntu derivative)
This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.
In my experience, systemd is much better documented, way more consistent, and way more reliable than what came before.
I guess it depends on your source of info but I've found what came before was pretty comprehensively & accessibly documented, at least as well as systemd, which - while well documented - suffers from sprawl & overwhelm of the docs. There's just SO MUCH to grok in comparison.
21 replies →
Maybe, but the scale of systemd features is humongous. It better be well documented. You don't need a user manual for hammer, you do need one for hydraulic press.
12 replies →
I'm still using sysvinit without anything on top (the default would have been sysvinit + openrc, but I dropped openrc, too complicated for my needs). I find it a lot easier than learning systemd, or learning anything else. To find out what's going on, I just need to open one file: /etc/inittab, and it's all in there. Nothing hidden somewhere else. Nothing undocumented. Simple commands, one after another. There are no dependencies, no conditions, not unless I put them there myself.
So, I disagree about your statement here, but let's for a moment assume it were correct - so let's not evaluate THAT particular statement, thus.
You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?
Shell scripts in general are crap. I don't understand why linux systems use them. When I transitioned to linux a long time ago, I wrote - and still write - pretty much all logic in ruby and .yml files. Literally my whole system is described via .yml files, ruby then just auto-expands all of this into what is meaningful. I also compile from source and manage the system via ruby as-is, so I don't even need systemd, nor shell scripts. But this is just one comment here and if you refer to shell scripts then I agree with you - shell scripts have always been horrible. I fail to see why we should like systemd merely because shell scripts are so awful. That makes no sense. I neither use systemd nor shell scripts (ok ok I bail ... I am currently using manjaro which uses systemd; I disabled most of the services, but the primary reason I was assimilated into systemd is mostly because the non-systemd linux distributions, kind of gave up for the most part or come with their own set of problems - slackware, void and so forth. And yeah, I was using and testing them for ages too, slackware I used for many, many years. It is still a great distribution but it is not really active anymore. No new .iso releases in years, sorry, that is dead. Even if Patrick still updates packages.)
The other part is ... IF you referred to an alternative init system, then THAT comparison is flawed too, because sysvinit is mostly just an init system. Systemd is some giant thing that does 100000 things. So the comparison is, and ALWAYS has been, unfair. Not the same things are compared here.
3 replies →
This has never been my experience for the whole duration of the systemd existence.
Well, in my experience, systemd has much worse documentation, is very inconsistent (or you could say it is constistantly brain-dead), and extremely unreliable and unpredictable, since it often hangs when shutting down and rebooting.
2 replies →
> Things not working the way I expect means I have to do more work to figure something out.
I dunno, "things not working the way I expect" is very subjective.
I personally think it makes more sense that processes do not outlive the parent from which they come (in this case processes spawned from a user shouldn't outlive that user) unless you explicitly go through something which outlive the parent (process manager in this case (e.g. running via systemd-run)).
Though I am also strongly of the opinion of just because something is a feature, does not mean it is good to keep around, e.g SUID/SGID (which has a similar "I get more than the parent" problem).
Though I guess different people can have different opinions/values on this.
It's one of those systemd features that are annoying and in the way when you're trying to accomplish a specific task but deal well with shitware. To be fair to systemd, these features can't usually be implemented without writing new rules for what you have to do to accomplish the legitimate tasks.
> This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.
Even if the change is a genuine improvement?
Yes. Improvement or not, a thing not working the way one expects means one has to do more work to figure something out. And in case of pid1, this is never a time spent productively.
I'm all for improvements and I love updates of software, but what systemd usually does is ideology and destruction in the name of "new". Like, we have had cron perfectly working for _decades_ until one man told us we were all wrong on that.
How can the change be a genuine improvement, if it does something unexpected that needs to be figured out?
This is not a genuine improvement:
> One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too.
Killing processes that the user clearly did not want killed is a regression.
Reading the rest of article it seems that its fixed but made things a lot more complicated than "unless you deliberately start things so that they keep running when you logout they will be killed when you logout". Am I wrong?
2 replies →
"The way you expect" is probably inconsistent and, upon closer inspection, completely broken.
There is a reason why systemd became the default and other niche init systems have faded into obscurity.
Sure, it may be more complex than your pile of shell scripts, but that's because it does the same things better, and has a lot more functionality that you will need at some point, and good luck replicating that by hacking shell scripts.
> "The way you expect" is probably inconsistent and, upon closer inspection, completely broken.
When I start a program, I want it to stay running. This is perfectly consistent and not broken.
You are framing this as the only choice being between systemd and shell scripts.
> There is a reason why systemd became the default and other niche init systems have faded into obscurity.
Yes, it is part of the Embrace, Extend, Extinguish strategy
1 reply →
I, for one, appreciate the honesty. I wish more systemd haters would admit this is why they dislike it. We could finally throw away the tired arguments that have been disproven in the past ten years
> We could finally throw away the tired arguments that have been disproven in the past ten years ...
Here's one you cannot disprove: the Jian Tan XZ backdoor did not affect Linux distro that weren't using systemd.
I know, I know, it's got absolutely nothing to do with systemd.
We're talking about something insane like upstream OpenSSH being modified to add systemd logs "log compression" to freaking OpenSSH (yay security, makes perfect sense!).
So disprove this: not a single Linux systemd-less distro was affected by an attempt to place a worldwide backdoor on Linux systems exposing a SSH port.
P.S: I moved all my infra to VMs that are systemd-free and containers, by default, do not run systemd as PID 1 (they don't run it at all). It works flawlessly. I'll now move my hypervisors to FreeBSD+bhyve and I'll be, at long last, totally systemd-free again (I was using Linux before "systemd-I-compress-logs-so-I-make-you-modify-OpenSSH-to-add-liblzma-dependency" came on the scene with it's its Windows-style .INI files and these were much better days).
> Things not working the way I expect means I have to do more work to figure something out.
You must love SELinux
The fault lies in the distribution for it's default configuration, not systemd.
The article even mentions that distros ship with it turned off
The fault lies in the upstream defaulting the option on, so that distros have to
> Things not working the way I expect means I have to do more work to figure something out.
Sound like you don't like computers to begin with
He probably just doesn't like having to use poorly written software
1 reply →
This is hideously annoying functionality for anyone heavily using detached tmux and screen sessions. Massively annoyed and such an unfriendly kdea.
While perhaps maybe sometimes useful on desktops, all this logind crap absolutely must be removed from servers.
Personally me I fail to see any scenario where this is genuinely useful.
Systemd is simply too complex.
The Linux kernel is simply too complex.
But how much of it is inherent complexity?
Only the pid 1 sigchild handling. Everything else is design choices.
About 0.1% is inherent complexity
Which part? Just saying systemd is like saying a distribution is too complex
I may be wrong but he was probably hinting at systemd being a constellation of too many parts.
As a user I can say that journald was a mistake, if you try to reinvent a database, you will reinvent it poorly and journald wasn't an exception.
I'm presumably missing something here. Why does tmux et al not work? Remotely? Ie you're logged in locally and remotely to the same machine, log out locally which kills everything running remotely, but then why would you log in twice like that?
And that being the case can systemd not just only close everything when your logins reach 0?
You can detach from screen/tmux, leave it running in the background, and log back in later to the same screen/tmux like you left it.
Except systemd can kill it when you log out, so you come back to nothing.
What I don't get is why (on Arch) I have linger off yet have never had trouble with tmux/ zellij being killed.
Edit: ah, this post clears it up. Mentions linger has nothing to do with screen muxers, and also brings KillUserProcesses to peoples attention.
Damn systemd and its multiple levels of convenience.
Ah ok. Seems like the log out metaphor is kind of broken then?
It seems to me if you want persistence between logouts, the processes should belong to a different group/user.
(I'm spitballing hypotheticalshere, not saying anyone/thing in particular is wrong)
2 replies →
LP knows better what should work for you and what not.
I never had a problem with systemd init despite its quirky habits like just giving up if a mount is bad in fstab, and I rather like systemd-networkd over the other four or five ways of managing the network. Systemd-timesyncd isn’t bad either.
But this, systemd-logind worrying about stuck processes in userspace is exactly the kind of scope creep that ends up justifying a lot of the hand wringing a decade ago. This thing bit me when it came out in a couple different ways and I am unapologetic in my dislike for it. So much so that it has caused me to drift away from Linux where I can. Even though it is a simple fix, I’ve become fatigued with userspace chaos.
Time to re-evaluate what the bazaar has become. Systemd is a common complaint, but it isn’t the only contributor to the fatigue.
[dead]