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?
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.
Systemd is not 1 giant thing that does 100000 things - it is a collection or 10000 services doing 10000 things, integrating amongst themselves where practical. You need not use networkd, logind, resolved or any other one piece of the system you dislike.
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.
I never found systemd difficult, but I do find prior solutions to be simpler. An init script is easy, and the order is also easy. If people are accustomed to UNIX systems, the sysvinit is better. For people who never experienced those systems, systemd is their friend. No need to use UNIX tools when Systemd ships with batteries included.
Yeah, init scripts are simple, but things get tricky outside of the happy path. Think of service upgrades/restarts. Once you care about dependencies, then you are back to a graph like systemd's.
talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel.
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
Absolutely not the case. Even relatively simple real world uses involved collections of shell scripts to carefully mount or initialize services in just the right order and would often fail with weird and infrequent timing glitches. With systemd that all becomes explicit, so of course it is awkwardly verbose. That is the whole point and a huge upgrade.
The problem is Ruby is not de-facto installed on most distros. Shell is the "universal" thing, but shell is actually not portable, even across distros. Perl is the only thing I'd qualify as both "sufficiently portal" and "universal". But then you have to write Perl, which nobody wants to do seemingly.
No way. I was easily able to create Systemd units from 0-knowledge, where the init system remains a big black box riddled with question marks for a very long time. Very little was documented.
We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before.
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.
> 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.
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.
> IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs
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.
I'm no sysadmin, except for my own systems, but I think that the vast majority of systems are fixed-config for their entire lifetime. Deployed once on VM and stays the same until it's no longer needed. So every sysadmin can just set them up in whatever way he wants with no obligation to make it understandable to the next guy. The VM will be deleted anyway when no longer serves it's purpose.
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.
systemd is a mono-repo with many interesting great useful projects that all make use of common libraries of functions so that no matter what tool you are using, they all work alike, they have predictable config interfaces, they have predictable operational patterns that work everywhere. thats a huge win for people who would rather have some overlap on the diagram of tools, than those people who (in their depraved madness, in my humble opinion) prefer zero overlap zero commonality zero familiarity as they snap together the different services daemons and handlers of their system. this is exactly the uniformity debate again and it's brilliant beautiful and blissful that there are scalable patterns that you can learn once and use again and again, as a developer, as an operator.
you either already knew and concealed, or you really don't have any clue at all, that those various tools you list are, in many cases pretty optional! the etc list is long there, so it's a little less clearly stacked towards optional (systemd-run/run0, systemd-home, systemd-nspawn, and so many other excellent robust great solutions that are optional). let's walk through your list:
the logger getting thrown in has indeed be a considerable point of contention. there's reasons not to be happy. i'm surprised no one juggles a fork that tracks main and does better, given how much vitriol and tears and bile have been shed over this, but yes it's still deeply integrated and it's kind of mediocre. to it's credit, part of what makes kubernetes such a compelling powerful force is that it is controller driven, and it does ok (not great) at a core requirement there: to find & track health status, events, so it can loop / autonomic itself. it's a scalable pattern that all software operations need. i don't know how you do systemd without having some kind of logging. i get that people don't like binary logs, don't like needing it, but a PID1 that doesn't have a consistent logging pattern is going to suck, and something had to be done there. maybe a more modular path could be explored. it would take so little effort to FAFO, to drop something else in, but no one did bother, and even in the LLM age, they still don't bother. the tears over this just feel so hollow today.
dbus is weird to put there, because dbus predates systemd and was already in most places well before systemd. it has been a core part of FreeDesktop for a long long time. there are some interesting desktop spaces not under that umbrella, but none that seem to try to make something similar or better. they just do without. they just don't let programs talk. they are alone.
now, i'm down for a KDE DCOP revival to see about replacing dbus; that would be fun, it was great machine-to-machine user experience, imminently automateable applications were amazing, unlike dbus, which is all under the hood (xopc excepting, still a gem in my heart for that, you crazy diamond). i would not characterize dbus as some you were forced to use it system. it's everywhere because it's damned useful and no one has any better ideas worth considering. agin, especially in the age of LLMs, the haters have every chance in the world to show off possible better futures, and dbus is still the desktop bus and no one is trying to disrupt that.
network and login and boot are all very optional and you can very much work without them. there's good alternatives for login that are drop in implementations of the very simple login services, so you can just do the core seats/sessions stuff however you want. lots of people do. login is an anti-example: it turns out replacing systemd components that are fairly integral with your own was actually quite easy. there's plenty of alternative boots, and always have been. i'll remind folks that systemd-boot wasn't even a systemd project: they just folded gummiboot in because it was so good, it still is nearly fully independent of systemd to this day but well maintained alongside systemd. there's plenty of network config systems/options, but, lo, people keep choosing systemd-boot. because its straightforward, well thought out, and once again does a far better job exposing the universe of different link and network types than anything else has and has a "you can just [do that]" superpower to it, because the text files are easy to work & drop-in config files rock the casbah. because it's ridiculously straightforwards and direct and such a breath of fresh air, such a simple easy to use text-file based joy compared to the demon nightmare zalgo geiger world of Grub, curse it so.
i do really really believe in a diversity of ideas, that we get better by finding lots of diverse interesting options, by resisting stagnation and getting stuck. i've posted some other posts to this, within the past week, over many years too, but, i really think we need a coalittion of people who are willing though, and not so much anti-willingness. people who want bigger better more bold, and who have constructive hopeful forward upward directions they want to go. open source as social glue is incredible impressive and helpful, has been such a net win, and we really are in such a better spot from kubernetes, from wayland, from systemd, from linux, from shells, that we all speak and know and that expose broad beautiful capabilities to the system up above it. and all of these processes have been somewhat difficult, are not decisions to take likely, and our outcomes are not 100%, that we could do better. but we still need to keep exploring frontiers and trying new things, nothing is sacred. i just really wish we saw a higher valence of concern & critique, that, when it came in, instead of coming in hot, could relish and enjoy what is, and suggest where to now, what above? it feels like all these magnets for hate have only eroders, only people angry that the world didn't stand still for them, angry that we don't all get to whiddle our own little beautiful weird quirky partly working never anywhere nearly as well tested or legible, never as communal system to their own content. i want room for those beautiful twiddlings, but it needs to matter, and it needs to compete with and exceed the mainline, as the mainline improves, advances, expands, for the greater common good. if you think you can provide greater common good, i need to see you explain how, and i highly suggest you have an answer that scales out, that improves conditions widely, that builds a better state of the art, that looks forwards.
Too long to comment on all items, but here's a few.
- You're right. I don't know much about systemd. It's incompatible with my view of how a system should behave so I refuse to use it. In fact, I'm more likely to use Windows 10 than a Linux with systemd. I can airgap a Windows and it's still functional. I can bring in games, programs, updates with a USB stick. On Linux this is borderline impossible.
- It is very difficult to replace systemd components on system that come with it preinstalled. Too many packages are built to depend on it's ecosystem. That's why most haters describe it as a cancer. I know this because of all the shit I have to go through to avoid them being pulled in on my systems.
- I see dbus+udev+ATK as infrastructure for spyware and systemd hard-depends on it. Everything that happens in a system, including user inputs, pass through that, and the default configuration doesn't follow zero-trust / least-privilege principles. It follows "it-just-works" principles, which are the exact opposite. The way any spyware would spy on Linux system would be through these 3 components. One compromised program connects to that and everything gets leaked. Also, the default configuration is set by the package manager. Do you remember that Ubuntu had an unremovable system package called "popularity-contest"? A distro that goes enshittified may add tracking, telemetry, etc. with no user knowledge. Unfortunately, everything already wants dbus. Even Firefox wants to manage my wireless connections. Enormous breach of privileges and everybody just accepts it.
- "greater common good" - No, browsers managing wireless isn't greater common good. Auto-starting services or a network connection because some app depends on it isn't greater common good. Players that publish currently playing song on dbus isn't greater common good. It's greater Google good (replace with your workplace or your favorite trillion$ corp). There's a difference. I'm sorry you can't see it. Greater common good would be a system where the user is always root and programs are always in their own namespace/container/VM with no possibility to talk to each other unless the user manually (not automated, not by default, not even by a confirmation) sets up a communication channel. A greater common good is a system where the user can't get an "access denied" changing a system setting, not because it has permissions, but because permissions don't apply to users as they interact with system settings, admin-utils, system files. Unfortunately, Android is closer to this principle than GNU Linux.
- Can't fork systemd. 1) Because Gentoo with all their resources, paid programmers, knowledge, etc. couldn't even keep eudev alive. You expect some guy in his weekends to maintain a systemd fork?? 2) Because it's pointless. The only useful fork would be a collection of stubs that fake it's presence to allow cancer-infiltrated programs to compile, but do absolutely nothing they ask (or fake it). Firefox wants to connect to bluetooth? No bluetooth nearby. Wireless? We're on an airplane. Location? North Pole.
the oss community has a phobia of having anything in common against all its reimplementations of the same thing. So systemd offers some consistency between distros: bad.
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
the systemd init system is complicated but fine. the problem with systemd is how much it wants your computer to itself. e.g. it can only run as PID 1, you aren't allowed to use control groups if you use systemd, it overwrites resolv.conf with its own address, it renames all your network adapters to lennart's preference (he calls them stable names but anyone who actually uses a computer will tell you they change more often now), and it binds itself to syslog
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.
that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up.
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).
Systemd is literally not a monolith because it's not one big piece of software. It's a collection of software. For example, systemd-boot has basically nothing to do with systemd-init.
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.
Just the PID 1 manager is multiple times larger in LoC than any alternative. There is no metric in which systemd is more lightweight that I could find.
I'm not sure this is true in practice, if we're counting init scripts themselves. Which we should, because init scripts are code and they often re-implement standard systemd features. Usually in wonky, broken ways.
What about other init systems? The GP said "any alternative." I am not familiar with how complex they are but was under the impression that there are a number much simpler than sysv init?
I think that even if we count init scripts which are way different level of complexity than C LoC, the Systemd would still be larger. Especially if we count just the scripts that are deployed.
Until it breaks, reports error, leaks, makes weird sound, needs a maintenance or even if you want to move it. You need to know how heavy it is, where are mounting points, where is the center of gravity, what needs to be affixed etc. What is the power it draws for the pump, what is the peak power and how long is the peak, what is the power factor? Does it have a safety certification, what kind of training operator needs, are safety elements up to date to modern standard? What kind of fire extinguisher do you need? What is the toxicity of all the materials under normal and extreme conditions? What kind of peak force is applied to floor and how is it distributed?
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.
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.
In my experience hangs usually happen from no time limits on units or excessively long time limits. I fried a NIC a while back and network-manager-wait-online has no time limit. Usually this isn't a problem, but the NIC was fried in a very unique way where it would continuously try to connect and then downgrade connections.
The bright side is this is all logged, trivially grep-able, and easy to fix.
> 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?
I don't think it's a regression at all. It's been standard advice for decades that logout-login wipes user processes for updates, therefore you don't need to restart.
I'd argue the opposite is true: linger is surprising, and I turn it off.
"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 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.
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?
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
Off the top of my head. Have a group that doesn't die on logout. So you can have an email Daemon that responds with out of office. And you tmux session can keep running?
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'
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.
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.
Systemd is not 1 giant thing that does 100000 things - it is a collection or 10000 services doing 10000 things, integrating amongst themselves where practical. You need not use networkd, logind, resolved or any other one piece of the system you dislike.
My least favorite part is journald. When you find a way to rip that out, let me know.
Also logind is so hard to avoid that even other systems have ported it: https://wiki.alpinelinux.org/wiki/Elogind
> You most likely refer to sysinit or something like that, right? Because to what else do you compare it to? Shell scripts?
dinit is a good service manager that doesn't feel obligated to reinvent the kitchen sink
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.
I never found systemd difficult, but I do find prior solutions to be simpler. An init script is easy, and the order is also easy. If people are accustomed to UNIX systems, the sysvinit is better. For people who never experienced those systems, systemd is their friend. No need to use UNIX tools when Systemd ships with batteries included.
Yeah, init scripts are simple, but things get tricky outside of the happy path. Think of service upgrades/restarts. Once you care about dependencies, then you are back to a graph like systemd's.
talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel.
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
How are hacky init scripts written in shellscript well documented? Can you point me to this documentation?
When are the init systems going to implement the basic security measures systemd has?
Which security measures are init systems missing? Are you saying all other init systems are badly documented?
take your pick: https://github.com/alegrey91/systemd-service-hardening - and this was 6 years ago and barely scratches the surface
If ever handled thousands of servers running Linux with sysvinit, you get quite accustomed to it… and the tricky bits aren’t that tricky.
> An init script is easy
Oh boy. Lmao.
Absolutely not the case. Even relatively simple real world uses involved collections of shell scripts to carefully mount or initialize services in just the right order and would often fail with weird and infrequent timing glitches. With systemd that all becomes explicit, so of course it is awkwardly verbose. That is the whole point and a huge upgrade.
I never used shell scripts for that. Ruby worked much better and easier. No glitches either.
I also fail to see how verbosity is a "huge upgrade".
The problem is Ruby is not de-facto installed on most distros. Shell is the "universal" thing, but shell is actually not portable, even across distros. Perl is the only thing I'd qualify as both "sufficiently portal" and "universal". But then you have to write Perl, which nobody wants to do seemingly.
So your systems have a dependency on ruby to startup and anyone who maintains it has to know ruby?
No way. I was easily able to create Systemd units from 0-knowledge, where the init system remains a big black box riddled with question marks for a very long time. Very little was documented.
We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before.
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.
> 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.
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.
> IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs
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.
I'm no sysadmin, except for my own systems, but I think that the vast majority of systems are fixed-config for their entire lifetime. Deployed once on VM and stays the same until it's no longer needed. So every sysadmin can just set them up in whatever way he wants with no obligation to make it understandable to the next guy. The VM will be deleted anyway when no longer serves it's purpose.
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.
systemd is a mono-repo with many interesting great useful projects that all make use of common libraries of functions so that no matter what tool you are using, they all work alike, they have predictable config interfaces, they have predictable operational patterns that work everywhere. thats a huge win for people who would rather have some overlap on the diagram of tools, than those people who (in their depraved madness, in my humble opinion) prefer zero overlap zero commonality zero familiarity as they snap together the different services daemons and handlers of their system. this is exactly the uniformity debate again and it's brilliant beautiful and blissful that there are scalable patterns that you can learn once and use again and again, as a developer, as an operator.
you either already knew and concealed, or you really don't have any clue at all, that those various tools you list are, in many cases pretty optional! the etc list is long there, so it's a little less clearly stacked towards optional (systemd-run/run0, systemd-home, systemd-nspawn, and so many other excellent robust great solutions that are optional). let's walk through your list:
the logger getting thrown in has indeed be a considerable point of contention. there's reasons not to be happy. i'm surprised no one juggles a fork that tracks main and does better, given how much vitriol and tears and bile have been shed over this, but yes it's still deeply integrated and it's kind of mediocre. to it's credit, part of what makes kubernetes such a compelling powerful force is that it is controller driven, and it does ok (not great) at a core requirement there: to find & track health status, events, so it can loop / autonomic itself. it's a scalable pattern that all software operations need. i don't know how you do systemd without having some kind of logging. i get that people don't like binary logs, don't like needing it, but a PID1 that doesn't have a consistent logging pattern is going to suck, and something had to be done there. maybe a more modular path could be explored. it would take so little effort to FAFO, to drop something else in, but no one did bother, and even in the LLM age, they still don't bother. the tears over this just feel so hollow today.
dbus is weird to put there, because dbus predates systemd and was already in most places well before systemd. it has been a core part of FreeDesktop for a long long time. there are some interesting desktop spaces not under that umbrella, but none that seem to try to make something similar or better. they just do without. they just don't let programs talk. they are alone.
now, i'm down for a KDE DCOP revival to see about replacing dbus; that would be fun, it was great machine-to-machine user experience, imminently automateable applications were amazing, unlike dbus, which is all under the hood (xopc excepting, still a gem in my heart for that, you crazy diamond). i would not characterize dbus as some you were forced to use it system. it's everywhere because it's damned useful and no one has any better ideas worth considering. agin, especially in the age of LLMs, the haters have every chance in the world to show off possible better futures, and dbus is still the desktop bus and no one is trying to disrupt that.
network and login and boot are all very optional and you can very much work without them. there's good alternatives for login that are drop in implementations of the very simple login services, so you can just do the core seats/sessions stuff however you want. lots of people do. login is an anti-example: it turns out replacing systemd components that are fairly integral with your own was actually quite easy. there's plenty of alternative boots, and always have been. i'll remind folks that systemd-boot wasn't even a systemd project: they just folded gummiboot in because it was so good, it still is nearly fully independent of systemd to this day but well maintained alongside systemd. there's plenty of network config systems/options, but, lo, people keep choosing systemd-boot. because its straightforward, well thought out, and once again does a far better job exposing the universe of different link and network types than anything else has and has a "you can just [do that]" superpower to it, because the text files are easy to work & drop-in config files rock the casbah. because it's ridiculously straightforwards and direct and such a breath of fresh air, such a simple easy to use text-file based joy compared to the demon nightmare zalgo geiger world of Grub, curse it so.
i do really really believe in a diversity of ideas, that we get better by finding lots of diverse interesting options, by resisting stagnation and getting stuck. i've posted some other posts to this, within the past week, over many years too, but, i really think we need a coalittion of people who are willing though, and not so much anti-willingness. people who want bigger better more bold, and who have constructive hopeful forward upward directions they want to go. open source as social glue is incredible impressive and helpful, has been such a net win, and we really are in such a better spot from kubernetes, from wayland, from systemd, from linux, from shells, that we all speak and know and that expose broad beautiful capabilities to the system up above it. and all of these processes have been somewhat difficult, are not decisions to take likely, and our outcomes are not 100%, that we could do better. but we still need to keep exploring frontiers and trying new things, nothing is sacred. i just really wish we saw a higher valence of concern & critique, that, when it came in, instead of coming in hot, could relish and enjoy what is, and suggest where to now, what above? it feels like all these magnets for hate have only eroders, only people angry that the world didn't stand still for them, angry that we don't all get to whiddle our own little beautiful weird quirky partly working never anywhere nearly as well tested or legible, never as communal system to their own content. i want room for those beautiful twiddlings, but it needs to matter, and it needs to compete with and exceed the mainline, as the mainline improves, advances, expands, for the greater common good. if you think you can provide greater common good, i need to see you explain how, and i highly suggest you have an answer that scales out, that improves conditions widely, that builds a better state of the art, that looks forwards.
Too long to comment on all items, but here's a few.
- You're right. I don't know much about systemd. It's incompatible with my view of how a system should behave so I refuse to use it. In fact, I'm more likely to use Windows 10 than a Linux with systemd. I can airgap a Windows and it's still functional. I can bring in games, programs, updates with a USB stick. On Linux this is borderline impossible.
- It is very difficult to replace systemd components on system that come with it preinstalled. Too many packages are built to depend on it's ecosystem. That's why most haters describe it as a cancer. I know this because of all the shit I have to go through to avoid them being pulled in on my systems.
- I see dbus+udev+ATK as infrastructure for spyware and systemd hard-depends on it. Everything that happens in a system, including user inputs, pass through that, and the default configuration doesn't follow zero-trust / least-privilege principles. It follows "it-just-works" principles, which are the exact opposite. The way any spyware would spy on Linux system would be through these 3 components. One compromised program connects to that and everything gets leaked. Also, the default configuration is set by the package manager. Do you remember that Ubuntu had an unremovable system package called "popularity-contest"? A distro that goes enshittified may add tracking, telemetry, etc. with no user knowledge. Unfortunately, everything already wants dbus. Even Firefox wants to manage my wireless connections. Enormous breach of privileges and everybody just accepts it.
- "greater common good" - No, browsers managing wireless isn't greater common good. Auto-starting services or a network connection because some app depends on it isn't greater common good. Players that publish currently playing song on dbus isn't greater common good. It's greater Google good (replace with your workplace or your favorite trillion$ corp). There's a difference. I'm sorry you can't see it. Greater common good would be a system where the user is always root and programs are always in their own namespace/container/VM with no possibility to talk to each other unless the user manually (not automated, not by default, not even by a confirmation) sets up a communication channel. A greater common good is a system where the user can't get an "access denied" changing a system setting, not because it has permissions, but because permissions don't apply to users as they interact with system settings, admin-utils, system files. Unfortunately, Android is closer to this principle than GNU Linux.
- Can't fork systemd. 1) Because Gentoo with all their resources, paid programmers, knowledge, etc. couldn't even keep eudev alive. You expect some guy in his weekends to maintain a systemd fork?? 2) Because it's pointless. The only useful fork would be a collection of stubs that fake it's presence to allow cancer-infiltrated programs to compile, but do absolutely nothing they ask (or fake it). Firefox wants to connect to bluetooth? No bluetooth nearby. Wireless? We're on an airplane. Location? North Pole.
Days since my last exposure to “I'm sorry, you're absolutely right, that's wrong”: 1
the oss community has a phobia of having anything in common against all its reimplementations of the same thing. So systemd offers some consistency between distros: bad.
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
the systemd init system is complicated but fine. the problem with systemd is how much it wants your computer to itself. e.g. it can only run as PID 1, you aren't allowed to use control groups if you use systemd, it overwrites resolv.conf with its own address, it renames all your network adapters to lennart's preference (he calls them stable names but anyone who actually uses a computer will tell you they change more often now), and it binds itself to syslog
The problem with systemd is not the init system. Most people who do not like systemd are happy with the init system, but do not want the rest of it.
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.
The scale is humongous? Syszemd is not one big thing. It's a collection of small things, each meticoulsouy documented and you can pick and choose.
If you still think there is only one Systemd, maybe learn about the tool instead of just talking others after their mouth.
that's wrong in the sense it won't be useful for anything unless you have a dozen of those small things setup in the very specific way the author envisioned you set them up.
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.
Yes, systemd not being a monolith is a myth.
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).
Systemd is literally not a monolith because it's not one big piece of software. It's a collection of software. For example, systemd-boot has basically nothing to do with systemd-init.
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.
It's literally not a monolith, but in practice it may well be, that was my point.
Just the PID 1 manager is multiple times larger in LoC than any alternative. There is no metric in which systemd is more lightweight that I could find.
I'm not sure this is true in practice, if we're counting init scripts themselves. Which we should, because init scripts are code and they often re-implement standard systemd features. Usually in wonky, broken ways.
What about other init systems? The GP said "any alternative." I am not familiar with how complex they are but was under the impression that there are a number much simpler than sysv init?
I think that even if we count init scripts which are way different level of complexity than C LoC, the Systemd would still be larger. Especially if we count just the scripts that are deployed.
> hydraulic press
What is there to know? It goes up and down, and don't stick your arm inside...
Until it breaks, reports error, leaks, makes weird sound, needs a maintenance or even if you want to move it. You need to know how heavy it is, where are mounting points, where is the center of gravity, what needs to be affixed etc. What is the power it draws for the pump, what is the peak power and how long is the peak, what is the power factor? Does it have a safety certification, what kind of training operator needs, are safety elements up to date to modern standard? What kind of fire extinguisher do you need? What is the toxicity of all the materials under normal and extreme conditions? What kind of peak force is applied to floor and how is it distributed?
You'd be surprised to know.
https://www.manualslib.com/manual/3389176/Cincinnati-90-Form...
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.
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.
In my experience hangs usually happen from no time limits on units or excessively long time limits. I fried a NIC a while back and network-manager-wait-online has no time limit. Usually this isn't a problem, but the NIC was fried in a very unique way where it would continuously try to connect and then downgrade connections.
The bright side is this is all logged, trivially grep-able, and easy to fix.
systemd is like the registry. If you drink the koolaid and fully admit and adopt the decisions made, you’ll do ok, perhaps even good.
If you have 20+ years of experience, you’ll will NEVER get it to work the way you expect, might as well install Gentoo.
> 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?
I don't think it's a regression at all. It's been standard advice for decades that logout-login wipes user processes for updates, therefore you don't need to restart.
I'd argue the opposite is true: linger is surprising, and I turn it off.
I I start a process with nohup and logout I clearly want it to keep running. That is the entire point of nohup.
If that process is killed when I logout then that is a regression.
I do not understand what this has to do with udaptes.
> Things not working the way I expect means I have to do more work to figure something out.
You must love SELinux
"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
No, it is part of the "I just want stuff to work" strategy
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).
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
That's pretty much all software.
This is hideously annoying functionality for anyone heavily using detached tmux and screen sessions. Massively annoyed and such an unfriendly kdea.
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.
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)
Think about user services in a multi-user setup
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
Off the top of my head. Have a group that doesn't die on logout. So you can have an email Daemon that responds with out of office. And you tmux session can keep running?
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'
LP knows better what should work for you and what not.
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
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 may be wrong but he was probably hinting at systemd being a constellation of too many parts.
[dead]