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.

You are asking the wrong question, my friend. You should be asking what doesn’t systemd do?

Once the kernel has loaded itself, it needs to start up userspace as well. This is usually (perhaps exclusively) done by starting an ‘init’ program as process number 1, which then starts up all the other userspace programs: systemd is no different in that regard. It solves a variety of problems that traditional inits have, though:

• rather than having near-incomprehensible shell scripts to start, stop, etc. all your programmes and services, it uses INI-style service files which are merely fiddly. They’re kept in a few logical places, not ‘everywhere’

• starting and stopping services is done with simple, consistent commands - systemctl enable tomcat will start the Tomcat webserver at next boot; start, restart, stop and disable do basically what you think. Shell scripts are… less predictable, especially between distros.

• rather than having to inspect all of your scripts and work out what order they start in, SystemD just lets you declare what they depend on, and it works it out for you - much simpler, much more robust.

• rather than needing a separate tool to manage scheduled events (usually a chron-like, like anachron), SystemD just lets you write a ‘timer’ with the same syntax as its service files. They can be set to only trigger based on other events, like start-up, so you can do once-an-hour database snapshots (but only if the DB is running) very easily. That’s painful with traditional inits.

• also manages disk and network mounts, so you don’t need a separate tool for those, and you can trigger other events off of them as well. That was also painful in older inits.

• and power events too, if you want to trigger other tasks before sleep or when your laptop wakes up. (Again, was painful before.)

• log files all in one place and controlled in the same way and accessed with one tool - again, traditional inits aren’t like that.

• (advanced usages) works well with cgroups, so if you’re looking to limit the CPU time on a web service and make sure that it only uses its share of memory, that’s dead easy. Very difficult with traditional init.

You can get a reasonable idea of what systemd is doing with a systemctl status at the command line; shows you the overall system status, with a nice tree view of what’s running and what caused it to start. Getting that kind of overview on a eg. SysV init is much less simple.

Administrators and devops generally love it; it’s very simple and straightforward and consistent and predictable. Certain devs dislike it, due to the original author, or feelings of overreach and complexity (although it’s much simpler than learning everything that it replaces), or because they’re attached to Bash scripts. (You can trigger Bash scripts with SystemD if you like, but they’re not ‘in control’.)

What exactly does systemd do?

Too much.