I am a Linux user, but I don’t really know how most things work, even after years of casual use on my Main, I just started getting into Devuan and wondered then, what exacly does systemd do that most distros have it? What even is init freedom? And why should I care?
What exactly does systemd do?
Too much.
Easier compared to what? Easier compared to sysvinit, of course. Easier compared to all the other alternatives? Six of one, half a dozen of the other, on balance, I would say.
But SystemD has inertia behind it now. If you run into problems, there are probably 1e10 web pages out there that will help you fix it. That’s why Debian solidified on SystemD: not because it’s any better than any of the others, but because it’s the same as everybody else.
cause ppl like me to say systemdeeznutz
Systemd is the first program that runs once the kernel has started. It’s job is mostly just starting up other processes, and managing those other processes. If you don’t know what systemd is, then you probably shouldn’t care about if you’re using it or not, it’s good software but there are fine alternatives.
What makes systemd particularly interesting is that it is different from historical init systems. Historically these init systems were an unholy mess of shell scripts. This offers maximum flexibility, but limits the functionality of the init system itself. Systemd replaces these shell scripts with simple ini-like service files that allow everything to be declared simply and declaratively, and allows specifying more rich metadata, like dependencies. But it’s different, and some people place a higher value on “how it’s always been” than pragmatism. I personally have zero sympathy for them because throwing out objective progress to hold onto a broken system designed for 1960s computing is just dumb.
I had to battle with the fucking initd and upstard before systemd. Those stupid headers of the scripts in /etc/init.d/ we wonderfully undocumented, didn’t have syntax checks, depended on a bunch of other shell scripts that didn’t have any damn comments in them.
systemd was going to happen sooner or later because nobody was going to put up with that bullshit forever.
Those people arguing about “do one thing right” blablabla don’t care about principles, they care about superiority. They want to feel like they’re the minority who can do stuff so that in forums they can be toxic and respond with “RTFM” or “LMGTFY”. They don’t want it easier and more functional, they want it hard so that they can gatekeep.
Like a bunch of Catholics: I experienced pain, so you have to too!
systemd can containerize services! To do that kind of stuff with initd, you’d have to know how create process-, user-, and network namespaces, and a bunch of other stuff.
I was with you until the last paragraph. Just about every init system is different from historical init systems. Do you really think OpenRC or runit or any of the other init systems people are using have any similarity to SysV init? I think you’re attacking a strawman in the last paragraph. (Edit: Except Slackware users. Slackware still does init the way it’s traditionally been done, but I can’t think of anyone else who does)
I mean to a certain degree, I can understand if people find a problem with Poetterings approach of doing things !CORRECTLY!. Like, systemd-resolved resolving A-records with multiple addresses ina deterministic fashion because it’s not defined not to be deterministic, and because actual load balancing would be better. It’s not wrong, but it’s breaking everything. And it got patched after some uproar. And there are a few things like that.
But at the same time - I don’t think people appreciate how hard doing process management right on linux can be, especially if the daemon to run is shitty. Like, init scripts just triggering the shutdown port on a tomcat - except the tomcat is stuck and not reacting to the normal shutdown port and now you have a zombie process and an init script in a fucked up state. Or, just killing the main process and for some reason not really removing the children, now there’s zombies all over the place. Or, not trying appropriate shutdown procedures first and just killing things, “because it’s easier” - except my day just got harder with a corrupt dataset. Or, just trying soft and “Pwease wexit Mr Pwocess” signals and then just giving up. Or having “start” just crash because there was a stale PID from an OOM killed process around. Man I’m getting anxiety just thinking about this.
And that’s just talking about ExecStart and ExecStop, pretty much, which I have done somewhat correct in a few init scripts back in the day (over months of iteration of edge cases). Now start thinking about the security features systemd-analyze can tell you about, like namespaces, unmapping syscalls, masking parts of the filesystem, … imagine doing that with the jankyness of the average init.d script. At that point I’d start thinking about rebooting systems instead of trying to restart services, honestly.
And similarly, I’m growing fond of things like systemd-networkd, systemd-timesyncd. I’ve had to try to manage NetworkManager automatically and jeez… Or just directly handling networking with network-scripts. Always a pleasure. Chucking a bunch of pretty readable ini-files into /etc/systemd/networkd is a blessing. They are even readable even to people rather faint on the networking heart.
I thought people hate systemd because it’s a resource hog compared to OpenRC. TIL i guess
What does exactly systemd do?
It mostly causes heated discussions and a feeling of nostalgia for simpler times.
When your computer finishes loading the kernel, you have to tell it what to do next. There are dozens of systems and services that have to run (once or keep running) for everything to work. Mounting your disk partitions, bringing the networking up, starting the GUI, initializing all kinds of services, etc.
Once upon a time most (all?) distros used sysVinit, adapted from Unix’s System V to do that. It was simple and very easy to understand and setup: Very basically the init program would call scripts by alphanumerical order (passing “start” to scripts starting with S and “stop” to ones starting with K). You’d place these scripts in /etc/rcX.d, X being a number, the runlevel (and you had just a handful of runlevels, like halt, reboot, single user, gui, etc). Want to run something between starting the network and bringing up sshd? Just create a script in /etc/init.d and link it to /etc/rcX.d naming it SNNmyscript, with NN being a number between the ones in SNNnetwork and SNNsshd. Want to disable a service? Change its script name from S… to K… Change startup sequences? Just change the NN.
Beautiful. But although it worked perfectly for most of us, it did have deficiencies. An obvious one is that it ran these scripts sequentially. Even if your computer was using 0.1% of its power to run each of them, you’d be waiting for each one to run in a single queue.
So a very nice and polite guy came up with systemd. Instead of simple scripts running sequentially, you could now create “unit files”, describing each “thing to do”, for what “targets” (similar to runlevels) that thing is needed, which scripts to run to make that thing happen, and which previous things should have been done before this thing (dependencies). With this, your computer can fire up multiple startup scripts (and stopping scripts) at the same time, only making sure to queue stuff so dependencies are met. For example, you don’t need to wait for sshd to start your database server, but you do need networking before you mount shared disks.
That made boot times much better, but at the cost of complexity and maintainability (and here come heated discussions…).
The problem is that not everyone wanted that tradeoff, but systemd was shoved down everyone’s throat as most (all?) distros adopted it.
So init freedom is a reaction to that, offering you the option of multiple init systems (there are more than just sysVinit and systemd).
No offense to all the other init systems, but I’d stick with sysV if you’re really after simplicity and backwards compatibility with most older systems (and the old ways), or systemd, because it became the de facto standard, it’s faster and more modern.
Should you care? If you have to ask this, then no.
If you had to craft your own init scripts and configurations, and had a ton of legacy scripts, or maybe were building very simple barebones systems, or very complex, always changing startup scenarios and targets or runlevels, or want to exercise your “freedom” just for the heck of it, then you could care.
If you’re a distro hopper (i.e. are more dedicated to “use Linux” than to use applications which run on Linux), having tried 5 different init systems may be one more thing to brag about in distro hopper meetings.
If you’re getting into Linux to learn Linux administration for career purposes, systemd is what you’ll find in commercial systems.
If you’re after an OS to just be an OS (i.e. just run your programs), just pick a well supported (community) and mainstream one, it will most likely come with systemd, and you’ll probably never need to touch systemd. My wife (not technical) has been using exclusively Linux for 15+ years, and I can assure you with 100% certainty that she doesn’t know which init system is there, or what is systemd or sysV.
If you’re new to Linux, curious and want to learn all you can about it, I’d say there are many other interesting and useful things in Linux to learn and care about before you go down this rabbit hole, summoning some nice nostalgic but outdated tech from the dead.
So if sytemd just tells the OS what to run next where does the complaint that it doesn’t “do only one thing well” come from?
Because systemd (the project) extends more than just systemd (the init system). It also includes things like:
- systemd-journald (system logging)
- systemd-timesyncd (Network Time Sync)
NetworkManagersystemd-networkd (network interface/connection management)- systemd-homed (Home directory management)
- systemd-resolved (DNS Resolver)
and so many more
Now, in my personal opinion, I do find it good in that these being under one umbrella project led to fairly good integration between these aspects of “system management” as a whole. But I do also concede that this may feel like too many responsibilities handled by one project
NetworkManager (network interface/connection management)
Pretty sure you mean systemd-networkd here. I find systemd-networkd to be very nice for headless systems, but NetworkManager seems to be a better fit for desktops because of the integrations it has available with KDE/Gnome/system tray
Why should you care? Tech diversity is good, and people can try out different approaches. Aside from that, there’s not a reason. Systemd is a really good desktop init.
What is init freedom? It means the init system can be changed without other software breaking because there is a dependency on some functionality of the init. In this case, a dependency on systemd. Although it’s probably a dependency on a subproject under the systemd umbrella rather then systemd itself.
Why systemd? It’s tailored to weirdnesses in the Linux kernel. The Linux kernel isn’t perfect, and it’s user land isn’t tied to the kernel. Systemd is a shim which papers over the oddities. I don’t remember which oddities, but they’re there and people ignore them.
Were there dumb decisions made? Yes, especially for the server side. I should test out some other inits for servers, but it ultimately works fine.
