Would anyone care to explain to someone who isn't 1337 in the inner workings of Linux, why systemd makes modern Linux not very UNIXY anymore and why everyone seems to hate it to death?
Fork/exec is the lightweight process inheriting of open i/o and memory state with copy-on-write which made Unix a joy to work with. It's a delightful mapping of kernel and userspace into complex inherited tree of processes sharing that origin state (or not. You can close it all down, change things.)
systemd is a complex mega binary which parses control files and subsumes several functions. It's big. It's not small like init. It's not fork/exec simple it forks control processes and monitors children and does a lot of work some daemons did themselves (getty, inetd) but others didn't do. And you get to monitor things. It's not unlike launchctl on OSX or other platforms. And after all /etc/rc is now 5 or more/etc/rcX.d/ complex substates of states to look for scripts, SAT solver complex dependency stuff between semi arcane shellscripts... blah.
PRO: everything is now much more consistent
CON: greybeards like me hate it (beardless btw but meh) because it's complex
gimme open-rc or gimme death
actually, sysv was fine too
open-rc solves the parallel-startup desire for people who want a faster boot and doesn't hide logs in binary formats which can only be interrogated with specialised tools - my primary reason for leaving Debian-based systems that I'd used for 16 years was having systemd forced on me and trying to deal with how to read good old system logging, not to mention 5-minute shutdown times, slower boot on the same machine than with Ubuntu's upstart or with open-rc.
> not to mention 5-minute shutdown times
5 minutes? Try total hang on shutdown, and often not starting up. That was my systemd experience. I traced it down to a NFS mount that no amount of tinkering would mount reliably pn boot. Granted that was several years ago, but soured me on systemd.
Yes, some things was improved but it could be done in sane way - making things by design replecable, as it was always in UNIX way. But systemd is intentionally self absorbing, more - looks like it is intentionally layer above Linux. Now what we can do when one day Pottering or anyone from that IBM/Intel/MS cabal will merge Linux kernel uncompatible change ? And make Windows kernel "working flawless" - for some time of course. And with build in tracing. Or login right licensing ? :) That can be easily done today. And what plain users will tell ? "Works for me, what you talking about ??" Remember, some idiots already tried to sell plant seeds that you needed to re-buy every year. Business unchecked becoming evil.
Btw. about that "boot fast" :> Now it is dropped, of course. Also making system gooing down almoust instant is broken for years now.
My prediction is that in some time facepalm will be most common reaction when someone hears "systemD".
Also, your listed “features” are bullshit: logging in, audio, GNOME, etc have absolutely nothing to do with systemd. Even logging can still be forwarded to any log tool you would like, but having it implemented inside is a sane choice — you have to start taking logs when there is not even a file system available. You know how was it solved in the pre-systemd days? It was simply ignored!
System init is a very complex problem, systemd only gives you the essential complexity for the task.
Also RE poweroff speed: there is a single flag you can toggle to either kill lingering processes (which is usually not enabled because some hacky tools like tmux likes to live in the background and systemd killing it is bad) or wait a bit before. So yet again, systemd does the correct thing while before these were simply killed.
SystemD is not an interoperable technology. It insists on wrapping itself around what was already there, in the guise of making it better while also making it impossible to use something else.
Abstract example: imagine systemd-plated manages access to crockery in your kitchen, providing neat features like being able to quickly pick out plates by colour (the old system never did that!). However, if you take a plate for yourself instead of asking systemd for it then systemd will take the plate out of your hands, put it back in the stack, and say “error: plate not requested via systemd”. Now imagine everything in your kitchen has to go through systemd. Now imagine that systemd is one of the biggest and most rapidly changing machines in your kitchen that breaks a lot. You’d be pretty annoyed if you ever did anything weird enough to encounter these bugs. If you only ever want a blue plate, you’re fine.
Real example: Any day now we’ll be unable to use plain LXC on Linux because systemd (1) assumes you only manage containers via systemd and (2) clobbers any changes you make outside systemd, using the lxc-* tools.
Systemd: Not that.
See https://news.ycombinator.com/item?id=29670980 for an example.
* lack of composability — This is what is really meant by the “do one thing” mantra. Plenty of UNIXY tools are bloated but they don’t feel like it because they can be called as filters. systemd is actually quite modular but the pieces aren’t designed to be standalone. Like how in Ansible is everything is a plug-in but it’s cumbersome to just run a single module.
* “better is worse” — one of the weirder faults of systemd is that it’s thoughtfully designed, handles edge cases gracefully, and does things the right way. Kinda odd to paint this as a fault but it’s the reason people like bash over powershell; Unix tools were mostly made by people solving their own problems and so are completely inconsistent, full of sharp edges, odd syntax and parsers, have plenty of unimplemented features but are fiercely useful. systemd is a tool not forged in battle and is designed by people trying to write good software over software that solves an immediate need. This isn’t to say that systemd isn’t useful — it’s genuinely transformative but software written out of frustration tends to be designed differently and it shows.
This isn't universal. For service management systemd is awesome, and has been way more enjoyable to use than any other system (Ubuntu's upstart, Solaris's SMF, FreeBDS, and old-school linux init). As a sysadmin my only issues with systemd have been occasional patches that required rebooting, but these have practically disappeared in the last few years.
That used to be many discrete programs and shell scripts and files.
There is a lot of philosophy to consider from there.
I really should have expanded on that post, and at a minimum removed "discrete programs" from it, the distinction being the behavior in shell scripts and such and sequential behavior at boot time.
It's a bit of a monolith. People will say it's not, because it's made out of a bunch of smaller components, but when those components are that closely interlinked it stops mattering if they live in different code bases.
It also has a pretty wide scope. PID 1 is responsible for things like dealing with zombie/orphan processes and it's generally a good idea to keep it as minimal as possible, and keep the attack surface as small as possible. Systemd handles things like socket activation, logging, scheduling, etc. It handles all this in more or less one process, which means that when/if that process crashes or has security concerns it's a much bigger deal. It even has it's own docker-equivalent!
Really you want to keep PID 1 as minimal and secure as possible.
>Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
They've made it hard to work with generic linux tools. For example they have their own custom log format that isn't text based. This means that linux tools like find or grep won't work on systemd logs. Generally systemd has replacements for those tools, like you can still grep but you've got to learn the specific systemd ways of actually getting the output and all that (note that a lot of distros seem to ignore systemd's logging provisions and just log to files like normal, for a bunch of stuff).
It's pretty complicated to reason about, one "unit" can be a bunch of different files spread out all over the filesystem, and it can be hard to get a good view of all the aspects that effect a unit without resorting to systemd-specific tools to figure out the relationships between things. For example if you want to edit a unit file the suggested way to edit a unit file is with something like `sudo systemctl edit ssh` or possible `sudo systemctl edit ssh --full` depending on the situation. Spreading files all over the place like that sort of betrays their enterprise roots, it makes some sense when you're working with very large teams but just having all the until files in one location (/etc/init.d) would be a lot more readable and manageable. Also having one file per unit, instead of having to have separate file for units and their dependencies (things like sockets) would be nice.
Another problem is that they broke chroot, which makes dealing with embedded systems that use systemd a pain if you're not using a systemd based host to develop on. They sort of force you to use systemd's docker equivalent instead of the more common chroot if you're dealing with systemd-based embedded systems. That means you'd better be running a systemd based host system as well.
---
Also I think some of us feel like it's being forced on us. Redhat/IBM funds or has control over a lot of the unix ecosystem, so when we see things like Gnome not working on BSD any more because it has a hard dependency on systemd, well it starts to look like an intentional.
Things like the systemd decision to randomly kill off screen/tmux sessions on user logout leave a really bad taste in some people's mouth. Honestly a fair bit of the dislike is just repeated instances like that, and repeatedly ignoring feedback as to why that's actually a pretty big problem, and generally being unwilling to compromise with the broader community.
https://www.reddit.com/r/programming/comments/4ldewx/systemd...