So long as this isn't to make way for Redhat's vision of systemd as the base system, I shrug.
systemd as base system will certainly happen, regardless.
My machines start much faster with systemd too, which is a nice side effect.
That's also when I learned systemd was running an entire virtual fstab layer. Because, you know, /etc/fstab just isn't good enough anymore.
I would file a bug on systemd mentioning this behavior. But I like the fact that that my usb wifi card will not screw my system.
What was intelligent about that?
I don't need intelligent tools, I need tools that do what I say! That's why they're tools, damn it!
Do you prefer sysvrc over -say- OpenRC, Upstart, runit, etc, etc?
I'm not sure how you could, with a straight face, claim that sysvinit fits this description. It does many things, none of them particularly well.
The only thing this accomplishes is ensuring no progress is made, ever.
It's a red herring, anyway. People have been replacing classic BSD and SysV initialization schemes since 1992 [1], but systemd was the first to penetrate the scene quite massively for a plethora of reasons that no one can seem to agree on.
Honestly that's unfair to XP/Windows Server 2003 which had much better supervisor capability than sysvinit provides.
That's really a shame. Systemd is almost comically bad.
I've seen a lot of political stuff, and a lot of claims that sysvinit ain't broke so we shouldn't fix it (which makes little sense to me), but haven't seen a good resource discussing technical merits, or the lack thereof.
I could probably do it, but in all honesty, the "debate" has been so spoiled that I doubt anyone would take it seriously. My relatively technical article about FreeBSD and launchd (which had only one error about where plists were parsed, a relatively minor gripe in the text) was near-universally misunderstood and derailed by commentators who went on rants tangential to what I actually discussed. Same with my init history article.
But, if enough people want to, maybe I'll bite the bullet. Not sure if I'd like to subject myself to it, but I think I might end up writing a rather long treatise if there's demand and I do go with it.
There are other pages out there claiming to be neutral overviews, but they generally just take a neutral tone while rehashing the same long-debunked myths and spreading FUD.
The specific thing I like about systemd is the init replacement. It's just so much better! Automatically tracking daemon child processes, even detached ones. Supporting all the different modes daemons work, so I don't need to write yet another damn clean-up-all-the-children function in a SysVinit script. It's wonderful.
But systemd is a lot more than an init system and I don't really have strongly formed opinions on those.
* http://blog.darknedgy.net/technology/2015/09/05/0/
* http://uselessd.darknedgy.net/ProSystemdAntiSystemd/
Another persons writings to read, for similar reasons, is Ian Sutton, who is the bloke who did SystemBSD:
You can't just go "attack surface" and have said anything useful, nor can you point at volume of code if that code is actually needed. All criticisms of systemd usually depend on people completely ignoring the very serious problems you can't solve with sysvinit and which do make actual, practical systems less secure (i.e. cgroup process isolation is amazing, and a lack of real service management is a huge problem and any service management is going to be running as root period. Yet there's been a real claim that service management is "what your sysadmin does". Why even bother with computing then?)
Here's an example:
http://lkml.iu.edu//hypermail/linux/kernel/1404.0/01331.html
Literally everyone with a clue in the matter seems to hate systemd with passion[1].
A long-term Debian Maintainer quit over the issue[2].
Linus himself (as you quoted) seems more than a little annoyed by systemd and its developer.
And yet somehow systemd made its way into all major distros...
Linus called out on some behaviour. That is not him saying that people should stop developing. It's him saying stop this behaviour.
Christopher Barry is most certainly not a troll.
As shown in the LKML and Debian debates, the systemd infestation was firmly opposed by nearly everyone outside the 'vested interest' RedHat filter bubble. And still is.
Some high profile names would be Eric S. Raymond or Patrick Volkerding (creator of Slackware).
Debian has been forked over this; https://en.wikipedia.org/wiki/Devuan
That is not him saying that people should stop developing. It's him saying stop this behaviour.
It's him finally calling Kay Sievers out for being incompetent and an asshole. Which was long overdue.
Sadly it's by far too late and will very likely not change a thing about systemd's "break and extinguish" strategy.
Systemd will continue to break other peoples projects in its effort to replace every mature service implementation with a hacked up systemd imitation.
At least until, hopefully, the major distros finally acknowledge their mistake and roll this disaster back.
1. It was not a good bug report. 'Do not parse "debug" command line parameter' is not a bug. The actual bug is "assertion in systemd-journald" which is a clear regression, but independent of kernel parameters. According to comments 17 and 22, it was promptly fixed.
2. According to projects process, discussions about design are to be done on the mailinglist and not in the bug tracker. Most commenters violate this.
3. No systemd dev explained why they parse the debug parameter.
4. Sievers closed the bug report without explicitly acknowledging the assertion problem.
5. The kernel devs (especially Linus) are too hot headed and misread this. Systemd caused and fixed (!) the assertion problem.
On the other hand, developers seem to enjoy it quite a bit.
That's what happens when you have developers developing for themselves, not for sys admins (the end users of their work).
Process management is built in and sophisticated (restarts, timeouts, conditions, limits etc.).
The dependency system is amazing for ensuring your system fails sensibly: I can link mountpoints to processes, and easily guarantee that a mail daemon only runs when its network mount is ready, and then make it also shutdown if that mount goes away for any reason. This is huge for self-documenting infrastructure - you can ensure that even manual intervention in the system won't leave it in a weird state, and the why is all right there.
Taking a conversation that started in public offline when there is an expressed interest in this very thread just doesn't follow.
Is it so hard to avoid change for change's sake? I'm not opposed to learning new things, but we're all really busy, and when the standard way of accomplishing things changes in every major release (which you're usually trying to deploy to stay on top of the latest developer demand, or audit requirements or whatever) just adds a massive learning curve. Now I've got to learn something new, rewrite a bunch of tools, all because.. why?
I don't expect it to change again in the next 10-15 years, except potentially to a competitor that is designed very similarly but just plain better.
I would like to see more empathy for the fact that systemd is a complex, underdocumented system. Lennart's blog series is great for the "why," but very sparse on "how" and especially "how do I fix it".
As a developer I go through that "new tech" cycle every 2-3 yrs. Why? 'couse world's evolving. Some evolution cycles are not necessarily good, but we have to steer the ship forward. It's not always nice, but I don't see the other way...
It took a while to get used to, but it does what I need very well (dependency resolution, process supervision, etc).
The arguments against it appear to be philosophical, not practical, and at no time have I encountered any defect in it. After a brief learning period I came to fully embrace it, and in actual use it makes my life easier in several minor but appreciated ways.
It's understandable that people become used to convention, and are resistant to change. However, most complaints about systemd seem to be appeals to tradition.
This is a comment I was supposed to send to chris_wot in the systemd v227 announcement thread, but his posts got nuked by dang.
Here goes:
----------------------
systemd tries to force various system resources into the Unit abstraction, to a rather mixed effect. Some are IPC resources (sockets), others are abstract entities which are driven by a lower-level primitive (services that drive jobs), yet others still claim to wrap resources but really drive util-linux binaries (mounts and swaps). The information hiding/encapsulation is inconsistent, too. I'm not shielded from the dirty details of transactions and the seven different job queuing modes, and when they actually blow up in my face, the debugging context is very scarce.
All of this takes place in an ad-hoc graph engine that I cannot really observe. I can look at approximations of it (systemd-analyze), but I have no way of directly manipulating it, only indirectly through normal operations on system and service state of which the effects I cannot reliably gauge as they undergo systemd's heuristics. Moreover, I cannot checkpoint the graph state to disk, so I could e.g. replay and reboot from a known-good system state manifest. systemd snapshots are ephemeral (in-memory) and moreover do not fully preserve the graph info, anyway.
systemd clearly has an identity crisis between whether it wants to be an eager or lazy service manager. Publicly, it recommends laziness through so-called socket activation, but in practice people mostly tend toward using the dependency system. The dependency system, of course, exists mostly to calculate ordering requirements for parallel startup. This however comes at a cost of non-deterministic ordering, whereby a service can be malignantly reordered, breaking the boot sequence (NFS seems especially prone). This is somewhat inherent to parallelism in general, but is particularly undesirable given parallelism serves no other purpose beyond startup speed optimization (for which process checkpointing I maintain is a better solution).
Between all of this intermediate complexity, I can end up in stuck start/stop jobs, cyclical transactions and dependency loops without knowing the exact origin, because the graph engine doesn't supply me with sufficiently good debugging context.
And the worst part is that most of this is not even a reliability/fault tolerance thing. The Unix process model has no semblance of anything resembling a "transaction", nor is the Unit object versatile enough. It's all heuristics on a private graph engine meant to topologically sort the edges, so as to accommodate systemd's dependency system (which conflates hard service relationships with softer ordering requirements, and is generally inflexible)... yet at the same time you're actually expected to lazy load everything, but barely so in the real world.
Oh, and of course, handling anything related to Unit objects in PID1 creates an unnecessary coupling between global system state and service state in particular, on top of all the intermediate complexity of the graph.
P.S. Interesting insights though, you make a few fair points. When I'm feeling better I might ponder some more on them. Peace.
Seems adding something to record how it started things and why it did so would help quite a bit. There's some debug mode where it limits how much it starts at once. Then some way to visualize this easily (not just a GUI/picture).
Whoa, please don't drop things like that casually in the threads. People are quick to believe them, but what you said is false. I didn't touch chris_wot's comments.
We never delete comments outright unless the author asks us to, and only kill individual comments (i.e. mark them [dead]) if we are banning a user for breaking the site guidelines, which was not the case here.
Overall I'll hire the sysadmin who knows the most init systems still found in common linux and unix systems and is the most ready to adapt to whichever trend wins domination. Evolve or die.
Can't have looked very hard, then. There's dozens of us. Dozens!
"Ok" with sysvinit, sort-of "like" systemd and "hate" supervisor.
Btw: almost nobody considers the point about supervisor. A lot of clients' systems I manage are sysvinit or upstart systems, which use the init system to start supervisord and then use supervisor to (poorly) manage some services.
So even if I get why someone might like sysvinit better than systemd, I have no idea how someone can like sysvinit+supervisor better than systemd.
Here's another one: I spent 18 mos in Google Site Reliability Engineering (and did a lot of pager work at startups before that) prior to transferring to software engineering, I think I can speak to both perspectives.
Systemd is incredible and is a huge advance in maintaining linux systems. It boggles my mind that anyone could compare it to what we were all doing before and walk away saying: "nah, I'll stick with the stringly-typed shell scripts and the stale pid files, thanks."
Specific technical reasons in favor /for sysadmins/:
- unit files are rigidly structured data and this is a Good Thing. Configuration is not code. Unit files are also very easy to write.
- systemd understands cgroups and manages them properly. Every single critique I've seen of systemd is from someone who either doesn't understand cgroups or doesn't realize why they are so useful and important. Cgroups manage jailing, process isolation, resource control (CPU shares, memory limits, block io shares, etc), privilege separation and dropping, etc., and this is all configurable by systemd using simple and declarative unit file directives. Like it or not, we are moving into a containerized world.
- machinectl is already useful for managing VMs and will only become more so as it matures.
- people shit on the systemd journal, but, I'm sorry -- you're wrong about this too. Structured binary logging is simply more efficient for this problem, both on the write and on the query side. The journal also can integrate with the systemd journals running in any VMs or containers running on your system, so you can get a unified and metadata-tagged logging stream of everything happening on the host
- socket activation enables zero-downtime restart/deployment for network services, any incoming connections to the port will be added to the listen queue by systemd before the target system comes back online