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[edit | edit source]
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
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.
Such Drama and Controversy[edit | edit source]
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.
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[edit | edit source]
- 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.