systemd is the most commonly used init and system service manager for Linux based operating systems. The vast majority of modern Linux distributions use it. It consists of a core package which handles system boot and initiation as well as run-time management of services. It comes with many optional modules for a wide range of services such as DNS resolution (systemd-resolved), time synchronization (systemd-timesyncd), home directory management (systemd-homed) and quite a lot of other basic system functions.
systemd users simple text-based
.service files to describe how system services should be launched and monitored. Starting, stopping and managing systemd-controlled services is done with the command-line systemctl utility. systemctl is, in broad strokes, used like this:
systemctl status outputs a list of running services.
A service can be started during run-time using
systemctl start servicename
and stopped using
systemctl stop servicename
where servicename would be something like
unbound or similar.
Services can be added to the list of things that should be automatically started upon boot with
systemctl enable servicename
systemctl disable servicename turns off automatic start of that service.
systemd has a lot of optional components who are developed as part of systemd. These are entirely optional. They can be used with systemd and some Linux distributions use them, others do not.
Among the more interesting systemd components are:
- systemd-homed is a entirely new way of managing user home directories on Linux systems. It is available in the systemd git tree but it is, as of February 2020, not yet part of any systemd release.
- systemd-machined is a powerful virtual machine manager. It can be controlled using the
- systemd-timesyncd can be used as a simple network time protocol (NTP) client. It is not nearly as advanced as fully featured time synchronization services like chronyd, but it does get the job done.
- systemd-resolved can be used as an alternative to running a local caching DNS service. It can also handle multicast DNS on a local network. It is not a fully featured DNS resolver, it can cache results from upstream DNS services but it can not do DNS lookups on its on.
Drama and Controversy
Systemd is probably the most controversial pieces of software in modern times. Many people are violently against it. It has been said that systemd is "THE EXACT OPPOSITE OF WHAT A GOOD INIT SHOULD BE."  and "Broken by design". We could fill pages upon pages with statements like these.
systemd brought about large changes to the way system initialization is done. Change can be very upsetting.
While some criticism is technically sound and valid the fact remains: systemd is the standard init and system management service. Resistance is somewhat futile.
It must also be noted that systemd is a lot more practical, manageable and powerful than sysvinit and OpenRC ever was.
- From: Linus Torvalds <torvalds <at> linux-foundation.org>
- Subject: Re: udev breakages - was: Re: Need of an ".async_probe()" type of callback at driver's core - Was: Re: [PATCH] [media] drxk: change it to use request_firmware_nowait()
- Newsgroups: gmane.linux.kernel, gmane.linux.drivers.video-input-infrastructure
- Date: 2012-10-03 18:07:10 GMT (1 year, 30 weeks, 6 days, 22 hours and 36 minutes ago)
- On Wed, Oct 3, 2012 at 10:24 AM, Kay Sievers <kay <at> vrfy.org> wrote:
- > Nothing really "breaks", It's "slow" and it will surely be fixed when
- > we know what's the right fix, which we haven't sorted out at this
- > moment.
- A thirty-second pause at bootup is easily long enough that some people
- might think the machine is hung.
- I also call bullshit on your "it will surely be fixed when we know
- what's the right fix" excuses.
- The fact is, you've spent the last several months blaming everybody
- but yourself, and actively told people to stop blaming you:
- bugzilla.redhat.com #827538
- and have ignored patches that were sent to you:
- lists.freedesktop.org 2012-August 006357.html
- despite having clearly seen the patch (you *replied* to it, for
- chissake, and I even told you in that same thread why that reply was
- wrong at the time).
- > I also have no issues at all if the kernel does load the firmware from
- > the filesystem on its own; it sounds like the simplest and most robust
- > solution from a general look at the problem. It would also make the
- > difference between in-kernel firmware and out-of-kernel firmware less
- > visible, which sounds good.
- So now, after you've dismissed the patch that did the equivalent fix
- in udev (Ming Lei's patch basically disabled your idiotic and wrong
- sequence number test for firmware loading), you say it's ok to bypass
- udev entirely, because that is "more robust".
- Kay, you are so full of sh*t that it's not funny. You're refusing to
- acknowledge your bugs, you refuse to fix them even when a patch is
- sent to you, and then you make excuses for the fact that we have to
- work around *your* bugs, and say that we should have done so from the
- very beginning.
- Yes, doing it in the kernel is "more robust". But don't play games,
- and stop the lying. It's more robust because we have maintainers that
- care, and because we know that regressions are not something we can
- play fast and loose with. If something breaks, and we don't know what
- the right fix for that breakage is, we *revert* the thing that broke.
- So yes, we're clearly better off doing it in the kernel.
- Not because firmware loading cannot be done in user space. But simply
- because udev maintenance since Greg gave it up has gone downhill.
- phoronix.com: Systemd In Ten Years Has Redefined The Linux Landscape (published December 20th, 2019)