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?
In a very basic description, systemd is your system schedule agent. It’s the component that kicks things off in order so all the vital parts start in order so they have the other parts in place before they load.
It’s reputation is muddy because it’s doing more than a single task and old fashioned thinking is that system components should only do one thing. It’s easier to configure but harder to understand than the older init
Systemd basically is what starts up other processes. You don’t need systemd, but you do need some init manager. Kernel loads, then calls up the init manager to load everything else. Anything you want to make run on startup gets added to the init manager.
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 thought people hate systemd because it’s a resource hog compared to OpenRC. TIL i guess
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 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)
It’s main purpose is to make some die-hards angry, I think.
After fighting with multiple network devices today, I feel like I have a right to be angry. Checking the info in dmesg what I see is that the system initially sets up all six NICs (two on the motherboard, four on a card) in the correct order with eth* names. Then something else comes along a couple seconds later (which I assume is systemd) and renames everything to enp* NIC names. If I move the card to a different slot or install a different card with the same model then all those enp* names change to something different, but dmesg still shows their initial eth* names in the expected order before being renamed.
“Predictable” names are anything but, and now you can’t even use the standard udev naming or even put link files under /etc/network/interfaces.d/ because all that stuff has been changed again so now I have to move all the link files to /etc/systemd/network/. I don’t know how anyone considers this a good thing when the convention keeps changing every few years and I actually have to do extra work to put the names back to what linux originally called them at each boot. Where does the madness end?
There is a grub argument to pass to the kernel that disables that renaming behaviour entirely.
Yep I’m aware of it. Seemed like it worked for a bit, then reverted back to the enp* names. And then all the pages I was finding for manually renaming the devices said to put the files under interfaces.d for deb11 but oddly it only seemed to read those link files for a few reboots, then it would revert back to the enp names. Found something about using OriginalName because the name changes were overlapping, that worked for a few boots and then reverted back to the enp names. So then I found something about a Path statement using the full pci device names, and THAT worked for a few boots and then reverted. So now I found out that the link files have moved to the systemd/network folder so I’m waiting to see how long that lasts…
And I realize it sounds like I’m talking about a system I’ve been running for years… I actually just put together this machine last Thursday. I had to start with Debian 9 because I couldn’t get any newer memory stick images to boot (this machine doesn’t have EUFI support), upgraded to deb10 and everything was still working as expected with the grub lines to disable renaming. Upgraded to deb11 and it all went to hell. I’m having some serious thought of trashing the machine and switching to deuvian now even though I really want to support debian.
If you’re using /etc/network/interfaces.d/ and all the NetworkManager related crap you’re doing it wrong. https://garajau.com.br/2022/01/configure-networkd-debian
https://tadeubento.com/2023/systemd-hidden-gems-for-a-better-linux/
cause ppl like me to say systemdeeznutz
