systemd

From LinuxReviews
Jump to navigationJump to search

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 is the brainchild of Lennart Poettering and Kay Sievers. They are currently in charge of systemd development at the behest of IBM.

Basics

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[1]. 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 httpd or unbound or similar.

Services can be added to the list of things that should be automatically started upon boot with systemctl enable servicename

and similarly systemctl disable servicename turns off automatic start of that service.

Components

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 machinectl commmand[2].
  • 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

Drama.jpg

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." [3] and "Broken by design"[4]. 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.

Torvalds opinion

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.
 
Linus

References

Links

Add your comment
LinuxReviews welcomes all comments. If you do not want to be anonymous, register or log in. It is free.