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.

When you boot up your Linux, it will mount the root file system and start one program. That program is systemd. Everything else on your system will be started through systemd or processes that systemd started.

That’s why it is important, everything else on your system is build on top of it. That’s also why it is difficult to replace, if you use something other than systemd, you need a completely new set of config files for that other thing or your software might not work properly. Most distributions have given up on that, as it’s just more work for a niche audience, and they just require systemd instead.

As a regular user you don’t really have to care all that much, most stuff systemd does will happen automatically in the background and be setup by your distribution. It can still help to get familiar with systemd tools like journalctl as that’s where all your error messages go and systemctl is how you start, stop or disable services on your system. If you use something other than systemd those tools won’t exist and something else will take their place.

As for why people don’t like systemd, it follows the kitchen-sink approach to software and does a lot of things at once. It replaced a whole zoo of smaller utilities like inetd, syslog, cron, atd, … Some people dislike this loss of modularity, while most the rest are happy that they have one tool that does all of those things well, especially since systemd can do a lot of those tasks better and in a more unified way than previously.

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.