Systemd

From LinuxReviews
Jump to navigationJump to search

Systemd is the most commonly used system management service on modern Linux desktops and servers. It handles system boot and initiation and run-time management of services as well as many other things such as DNS resolution, time synchronization and quite a few other things.

Systemd is the brainchild of Lennart Poettering and Kay Sievers. They are still in charge of systemd development at the behest of IBM.

Basic usage

Linux systems running systemd, and that's most of them (Debian/Ubuntu/Fedora/CentOS), can in broad strokes be managed 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.

Such 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." [1] and "Broken by design"[2]. We could fill pages upon pages with statements like these.

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