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?
As mentioned in the second sentence of TFA. Debian enables linger by default.
It bit me on pop os (the Ubuntu derivative)
Personally me I fail to see any scenario where this is genuinely useful.
systemd is awfully documented (volume is not quality), things are still changing and haven't even caught up in functionality with any init hack.
the only saving grace of systemd is that it almost makes it easier to use namespace and other sandbox (but only because those are newer and init systems also didn't have their solutions up yet)
systemd only purpose is to mimic windows administration in linux. sorry of anyone who fails to see this
When are the init systems going to implement the basic security measures systemd has?
Oh boy. Lmao.
I also fail to see how verbosity is a "huge upgrade".
Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either forked off some other skeleton or having been made on it's own at some point.
And then companies wanted to do the right thing and apply some capabilities restrictions to processes. They wanted a little more than out of box security. That results in every company forming and modifying init scripts, changing the configuration paradigms, encoding config directly in or inventing their own new parameterization.
The fact is I don't have to look at docs any more, because everything has a (pleasant) uniformity. The fact is we are worlds better at securing and locking down our processes, because systemd has incredible built in options for capability, sandboxing, and other fantastic security processes.
> There's just SO MUCH to grok in comparison.
There always was before too. Most people skated along the surface, but when some daemon tried to actually have better practices, do some security tightening, operators were in for that exciting rabbit hole of trying to catch up and learn. Or just hand wave it away.
I think this statement really iconifies the systemd resistance really. Yes there is so much (imo: enjoy it, isn't that so great?) It's many many many latent possibilities (for you to over time learn): it's so often what the kernel is offering you, it's well exposed, and you have a pleasant uniform system for harnessing that, that you only have to learn once and which can pay dividends again and again and again once you learn it. Learn once, use many.
Or just ask your LLM. It knows. It will just tell you. It won't have to read docs or source. It knows systemd very well. Because it is something shared, something known. Imo it ought be something treasured.
I'm fine if some day we get rid of systemd. Nothing sacred here. But to attack it, it must be attacked from above. It must be replaced by something with more principled and more capabilities. Same as Kube. Neither is going away, neither will ever be displaced by smaller offerings. The only way out is through, the only way out is up. Godspeed, good luck, have fun.
> And then companies wanted to do the right thing and apply some capabilities restrictions to processes. They wanted a little more than out of box security. That results in every company forming and modifying init scripts, changing the configuration paradigms, encoding config directly in or inventing their own new parameterization.
IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs. Those file are just that - templates. The fact that overworked company sysadmins started using templates as final configuration and needed something automated instead, doesn't mean that this systemd that is fit for them is also fit for everybody else.
That, IMHO, is the other 90% of the problem (to riff on the ninety-ninety rule).
Every competent sysadmin has their own particular style & preferences & opinions about what the exact shape should be. And will go rewrite the world, according to some particular set of tastes, that they usually won't write down or document or socialize.
So not only do you have to figure out all the special sauce in how the service you just walked in to is managed, you have to wade through a complete re-architecting that some sysop made on their own judgement 5 years ago that people have patched and hacked since.
You can keep adapting to these scenarios. But to me, the normativity, the incredibly great toolkit of options it comes with: yes it's sizable, but it's one thing that I have to learn, that is usually a direct representation of something the kernel gives me, that will then be familiar and portable and useful wherever I go. This feels so much more civilized than what came before.
That being said, I do understand the need for some standardization. But you missed this part:
> doesn't mean that this systemd that is fit for them is also fit for everybody else.
They practically forced everybody to use it, and not just the service manager, everything else too: init, logger, network, login, dbus, etc.
X11 was pretty much standardized, that won't do.... let's invent wayland but make sure that there are multiple incompatible implementations of it!
and so on. I love linux, but this sort of mentality is ridiculous
What is there to know? It goes up and down, and don't stick your arm inside...
https://www.manualslib.com/manual/3389176/Cincinnati-90-Form...
If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.
you seem to be repeating all the marketing, while mentioning in other comments you never understood any init system. i don't think you're the authority to be adding so many comments here.
You can forward logs to rsyslog or something, but you really can't disable systemd-journald. Technically you don't need to run systemd-boot, you can use grub or something else, but then bootctl and systemd kexec stop working. You don't need to run dbus, but if you don't several systemd features break, and it's not even documented what needs it. The list goes on and on.
Also, the fact that all components are in the same repository and need to be built together causes a lot of headaches with packaging due to dependency cycles (like, systemd -> cryptsetup -> lvm2 -> udev -> systemd).
Yes, some software is more tightly coupled than others, naturally. systemd-init and systemd-journald work tightly together because logging is a core requirement of any init system.
The bright side is this is all logged, trivially grep-able, and easy to fix.
If you have 20+ years of experience, you’ll will NEVER get it to work the way you expect, might as well install Gentoo.
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.
Also logind is so hard to avoid that even other systems have ported it: https://wiki.alpinelinux.org/wiki/Elogind
dinit is a good service manager that doesn't feel obligated to reinvent the kitchen sink
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.
Even if the change is a genuine improvement?
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?
I'd argue the opposite is true: linger is surprising, and I turn it off.
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.
When I start a program, I want it to stay running. This is perfectly consistent and not broken.
Yes, it is part of the Embrace, Extend, Extinguish strategy
You must love SELinux
The article even mentions that distros ship with it turned off
Sound like you don't like computers to begin with
And that being the case can systemd not just only close everything when your logins reach 0?
Except systemd can kill it when you log out, so you come back to nothing.
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.
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)
Do you want user-level services, or a multi-tenant system-level service? - Who can tweak the service configuration? - How do you ensure there's no data leaks between users? - What about misbehaviour? Quotas, crashes
I think lingering is great here
I'm not necessarily talking about the Unix concept of a group. It seems to me you want some granularity between 'kill all processes' and 'keep all processes'
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.
I think it's just popular to dislike systemd, some sort of echo chamber effect or something.