I think the disconnect we're having is your inability to perceive complexity. And I don't blame you, it's not easy to quantify. I suggest you start with, Out of the Tar Pit by Ben Moseley. I'm not knocking on documentation, it's a vital property that I consider when adopting new technology.

What I'm saying is that systemds documentation currency (if you accept my metaphor) is spent on covering its accidental complexity and it's voluminous. If you disagree with me, that's fine. This is just my experience as a linux user that's had to deal with systemd.

If your claim is that systemd man pages are well written documentation then I think you're exaggerating and I'll wager you've relied on stackoverflow examples or tutorial blogs to solve your systemd issues--because I have. The reason for this is because the number of concepts and abstractions that you have to piece together to solve your problem is massive. But yeah, it's just a 5 line Unit file. I prefer strawberry kool-aid, thanks.

I genuinely don't see what's so complex about a service unit file. It's a simple INI file that has multiple sections that describes the service, tells what command to run and specifies any dependencies. It's literally the same thing that init scripts do except in a much more concise and efficient manner. And as I said before, there's a ton of systemd service unit files on any Linux system that you can take a look at and use as inspiration for your own services. Taking a little time to learn the ways of systemd is not a huge burdensome task like you're making it seem to be. I don't see why you think everyone should conflate systemd with complexity.

And about the voluminous documentation, well man pages are supposed to be comprehensive and cover every single aspect of the tools being described. They're not there to just be an intro to systemd for new users and administrators. If you want something like that, look no further than the "systemd for Administrators" series of articles written by the systemd author himself. https://github.com/shibumi/systemd-for-administrators/blob/m....

> I genuinely don't see what's so complex about a service unit file

It't not the unit file that's the problem, it's the mountains of junk, low quality C code written by an obnoxious, arrogant twit named "Linux Puttering" who has proven for 15+ years he couldn't care less about code quality or system reliability.

Besides the anecdotes shared by others over the years about the horrible experiences they've had with systemd, I have one of my own to share. When developing my own distro to escape the bloated, laggy hell that is Ubuntu, I started the build on my existing Ubuntu system. I found out the hard way that accidentally double mounting virtual filesystems on the target volume causes systemd to crash the system after about 60 seconds, with no possible way to recover. On MY system, with no junky ass systemd, making this error harms nothing at all and can be easily fixed.

The people who talk about "buggy, hacky" shell scripts appear to be some of the same type of people who shrink in horror from the idea of compiling their own kernel, or working at the command line. (i.e. not really "hackers" at all.) There is nothing at all wrong with using shell scripts for startup. It is in fact the simplest, and IMO most elegant way of doing the job, and no it isn't buggy or hacky in the least. The file system is the database and unit file and the already existing shell is the interpreter.

My system starts much more quickly than Ubuntu and is much faster and more responsive in daily use also, so the "startup time" excuse is a myth, and practically all of the other contrived examples people use to justify the use of systemd can be done BETTER using shell scripts in conjunction with small, light weight, single purpose utilities built the UNIX WAY.

It's "just an INI file" but you would have to understand what the thing that's interpreting does. All the stuff that the OP described as a positive - dependencies, auto-restarts, socket activation - somewhere there's a codebase that's implementing all that, and you can't just understand your "config file", you have to understand what that codebase is actually doing with all of its concepts. Elsewhere in this thread someone writes about how great it is that systemd is using a cgroup namespace to keep track of each process instead of a PID, and maybe that is great, but it's yet another new concept that you have to understand to understand how any of this works. Etc.

You could say that a shell script is a config file for bash, and you have to understand bash to understand what it's doing. But a shell is both simpler than systemd, and something that anyone working with Linux already understands.

The equivalent comparison with init scripts would be all the documentation and complexity of every program invoked by the init scripts, not just by sysvinit or rc's documentation and complexity directly. systemd just has most of that built in. And if you're using socket units, the order of what order to start things is essentially outsourced to the kernel, so that's a bit of a simplification.

Try building and maintaining a linux distro without systemd, especially for a large organization that needs to write their own init scripts. And especially when a large number of the devs in that org aren't shell experts, or don't understand the difference between /bin/sh and /bin/bash. And so on.

Here's another example: https://lwn.net/Articles/701549/ before systemd, for complex NFS setups, the sysadmin _had_ to write the init scripts per-site or per-machine. With the solution in the article (systemd generators) one set of unit files shipped by the distro solves the problem for over 99% of users, including most of the aforementioned complex setups.