Why systemd is the way forward: technical arguments

[edbarx]

For the sake of balance, let us invite our systemd supporting fellow members of this forum, including DDs, to post their reasons behind their support for systemd.

U-turns are not impossible, even for world-famous politicians, let alone mere Debian users.

I am not afraid of making a U-Turn if the arguments presented prove systemd is superior to other similar initialisation daemons.

[thanatos_incarnate]

Non-technical user here, so no professional answer to why it would be better.
I am therefore neither pro, nor against systemd.

My observations thus far:

+ shorter shutdown/hibernate/suspend commands than before with dbus, whatever
+ works as before, but boots faster
+ no bugs thus far on Debian Jessie (both with a full fletched KDE4 installation,
as well as just a lean WM environment)

- from what I can gather, we will have to learn some new commands
- systemd seems to take up more space, but it seems trivial on today's cheap storage
(not sure how that behaves on embedded devices)

[confuseling]

This is worth a read:

https://wiki.debian.org/Debate/initsystem/systemd

[buntunub]

Non-technical user here, so no professional answer to why it would be better.
I am therefore neither pro, nor against systemd.

My observations thus far:

+ shorter shutdown/hibernate/suspend commands than before with dbus, whatever
+ works as before, but boots faster
+ no bugs thus far on Debian Jessie (both with a full fletched KDE4 installation,
as well as just a lean WM environment)

- from what I can gather, we will have to learn some new commands
- systemd seems to take up more space, but it seems trivial on today's cheap storage
(not sure how that behaves on embedded devices)

I boot my desktop up only after power outages. That's roughly once every year or so. Same for my servers. Why are boot times even being considered as a plus for Systemd when they are trivial with SysVinit as-is?

Yes, I have read that wiki for Systemd. More than once. I see nothing listed in there that really appeals to my way of computing. TBH, I see nothing in there that should appeal to any sysadmin.

[confuseling]

Systemd uses control groups to ensure that any service, regardless of
its state, can be shut down properly.
Systemd extends the logging features of the system in many ways with
journald, and can remain integrated with the existing rsyslog daemon.
Logs are in a structured format, attributed to filename, line of code, PID
and service. They include the early boot (starting from initramfs). They
can be quickly filtered and programatically accessed through an efficient
interface.
Systemd’s virtual TTY management allows real multi-seat support, and
revoking access to input devices on session switch.
Systemd can trivially add security settings to a service without any need
to patch it: user/group change, chroot, private network, private /tmp,
read-only access to parts of the tree, tcp wrappers, filtering system
calls, ? NoNewPrivileges (kernel feature to avoid privilege changes),
limiting effective capabilities, limiting whatever the kernel provides in an
integrated manner (device bandwidth, CPU usage, memory usage, OOM
settings, nice levels, timer slack, ulimits…)
Systemd’s centralized service startup and monitoring makes it much
easier to setup high-availability using software like heartbeat or
pacemaker.
Systemd ships a growing number of useful, unified command-line
interfaces for system settings and control (timedatectl, bootctl,
hostnamectl, loginctl, machinectl, kernel-install, localectl). In Debian,
they use the existing configuration files without breaking compatibility.
In addition to command-line interfaces, Systemd provides a D-Bus API
to control service management and access system settings, as well as
bindings to do that from Python, node.js, php, lua, Qt… GNOME is
relying on these services, and it is likely for KDE and Xfce to use pieces
of it in the near future. They are not specific to systemd per se , but so
far it is the only implementation.
Systemd can run without any configuration change in a virtual machine
or a container. It will automatically skip unwanted services.
Systemd provides full watchdog support. If configured to do so, PID 1
will enable the watchdog and will perform the watchdog notifications
itself. Suitably configured services use systemd as the watchdog, and
notify it regularly to be considered alive. In this way, the whole system
is supervised, with the hardware supervising systemd, and systemd
supervising the rest.
Systemd can be used used inside the initramfs (see dracut on Fedora),
which means the same code serves an additional purpose, and there's
less stuff to maintain. It can also hand control back to the initramfs at
shutdown, making it possible to cleanly unmount the root filesystem
even in very complicated, stacked setups.
Systemd is introspectable and easy to debug: in addition to the ability
to provide debugging output and a debugging shell much earlier in the
boot process than other boot systems can, systemd features command-
line and GUI tools to debug the state of individual services and
understand precisely why they fail to work correctly.
Systemd is moving strongly in the direction of configuration-less system
( i.e. “empty /etc/”). So /etc/fstab might be empty on a system with a
GPT partition table, with partitions mounted in appropriate places based
on their type id. This means that the configuration of the common one-
machine-one-disk setup becomes even simpler.

None of that sounds useful to you?

[twoflowers]

It does make sense, but it's just an other way to say "we place a layer over what we had and call it soooo cooool - and what we did not understand we broke thoroughly and call it soooo coool, too"

e.g. logs: have you ever heard of a system that changes logs after they got written? well, here it is, it's systemd! cool, aint it?
e.g. "configuration-less system" ... aka "registry" .. wait, windows has one and it's soooo coool!

[thanatos_incarnate]

Boot times and fast resuming are important for embedded devices.

[confuseling]

If it were a mere obfuscation, sure. But it isn't - it does things like process monitoring that weren't done in the core system before.

You can use conventional logs if you want to.

And nobody complained when xorg.conf disappeared, did they? The system automatically configuring itself sanely is emphatically a good thing, as long as it respects manual configuration too.

[TobiSGD]

I boot my desktop up only after power outages. That's roughly once every year or so. Same for my servers. Why are boot times even being considered as a plus for Systemd when they are trivial with SysVinit as-is?

Not everyone has the same use case as you. If you start a non-trivial amount of VMs or containers, preferably on demand, on your servers then even one second longer boot time will add up quickly, both in used resources and reaction time. Having said that, improvements in boot time is not actually a plus for systemd, but a plus for parallelization of service startups where possible. My systems start exactly as fast with systemd as with OpenRC with parallel starts enabled.
So I see your point, but it is not valid for all use cases. Nonetheless I agree with you, improved boot times should not be an argument for systemd, since they are not a systemd-only domain, but merely a side-effect of a design decision other init systems also make use of.

@twoflowers: I guess you mean stateless systems, not configurationless systems, but even then comparing this with the Windows registry does not make sense at all. If you care to come up with a technical point and show us where you think this will lead to a registry-like design I am happy to discuss that with you.

So, some of the dvantages I see for me with using systemd:
- consolidation of commands and functions, read: one command for one specific area of functionality, systemctl for managing everything regarding system states, timedatectl for anything time/timezone related, journalctl for anything with regards to logs (if you decide to use the journal), ..., and with that consolidation of server management, it doesn't matter if you are logged into a RHEL, Suse or Debian server when managing services, if all of them use systemd
- integration of VM/container-management, it is just convenient to to able to control and inspect the init system of a container without logging into it, all I wait for is that they add Docker to the list of supported managers
- easy and straight forward setup of my network, uncluding bridges and stuff, using networkd
- documentation, the man-pages are good and most of the time you will find tutorials written directly by the authors

- something that often time is mentioned, but only indirectly affects me: consolidation of common functions and offering. APIs for them, so that they don't have to be implemented over and over again in the actual services or daemons, like privilege dropping, session management, daemonization of processes, ... . Though this only indirectly affects me (besides making my systems more secure), due to the fact that I am not a developer, this is the point that many people have issues with, since this is the part where projects that decide to use those APIs add a dependency on those APIs to their project, read: other people shout at them for being depending on systemd (while in fact they are dependend on APIs that anyone can provide), or, more often, shout at systemd developers for forcing themselves onto anyone and being cancer or a virus, instead of offering those APIs for their init system of choice (or init system independent).

- The most compelling reason for me is: they actually go forward and do it. Many of the things I mentioned can be done without systemd, a point that often comes up in discussions. The point is that nobody is actually doing it, while the systemd developers just go ahead and offer those services, neatly integrated into one modular project, where it is easily usable and testable.

Many things that now matter to me and are only offered to me by systemd (yet?) are things that I did not care about before actually trying it myself, which is why I encourage anyone to just give it a try with an open mind to see what it can offer for you if you are willing to spend some time learning.

systemd has changed my way of managing my systems in the same way as switching from floating WMs to the tiling ones: at first it was confusing and sometimes hard to grasp, but after some learning I really started to like them and nowadays I am seriously annoyed when I only have floaters available for use.
Or when I started to use Vim instead of nano, hard for anyone used to nano at first, but after a little learning powerful and convenient, even a little bit addictive (I had to add an alias named :q to my shell configuration because I started to getting a lot of 'command not found' type errors when trying to close a shell).

[RU55EL]

[...]So, some of the dvantages I see for me with using systemd:[...]

I'm sorry if this is off topic, but this spelling error made me laugh! (Speaking strickly in the context of humor)

dvantages = positive attributes of systemd

[Head_on_a_Stick]

http://dontboycottsystemd.org/

http://www.reddit.com/r/programming/com ... te/ch0maow

[tomazzi]

Boot time is becoming highly irrelevant on desktops/laptops as more and more PCs are using SSDs as the main drive.
<true> Servers on the other hand, (not talking about home-brew PCs which are funcioning as servers), are using extremely fast and redundand Raid arrays, which are usually even faster that single-SSD configurations. When the system is running, then starting another OS in the VM is even faster - due to multiple caching effect : OS cache + Raid cache + VM (OS intrernal) cache - eg. even with a normal HDD used for a VM, shitty winblows works 10x faster than as a host OS - so please, boot time is the least important thing to mention with regard to systemd.

I like the idea behind the systemd - however, there are two aspects of using it:
- as a service and boot manager - works ok (usually, in common configurations)
- extensions for systemd (like DNS resolved daemon - it lacks of even most basic protection <not to mention RFC> against cache poisoning) are completely broken, untested piece of crap.

Although it works ok in common cases, then still the problem is, that it wasn't really tested - nobody, including RedHat haven't a chance to do this, because it changes so frequently (should I mention that libsystemd-logind, currently used by Jessie, is now obsolete?).
Another fact is, that even an average C programmer, after reading the sources can confirm, that the code is a crap, wich lacks protection against segfaults and there's totally no protection implemented in release builds...

What's strange - somehow, it happenned that people in Debian are blindlessly repeating bullshits stated by the authors:
<From wiki>

Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.

Explanation: this is impossible and/or dangerus - Yes, systemd can kill each service easily, very much like the "WaitToKillServiceTimeout" setting in Winblows. It's a total bullshit or simply a lie that it's safe to "shutdown a service regardles of its state"

That beeing said, I'm convinced that systemd can be fixed/forked - and this is the only solution to stabilise its code, because the authors are apparently using the RedHat position in the market/Linux word to experiment on us - users, and they are not interested in freezing the systemd anytime soon... (what means that Debian uses alpha-level software, which just happened to work somehow)

Regards.

[TobiSGD]

- extensions for systemd (like DNS resolved daemon - it lacks of even most basic protection <not to mention RFC> against cache poisoning) are completely broken, untested piece of crap

Seriously? You use the state of a part of systemd that is in early development and discouraged to use in the current state by its developer as indicator for the quality of all parts of the tree besides the core components? Way to go!
http://lwn.net/Articles/622445/

[buntunub]

What's strange - somehow, it happenned that people in Debian are blindlessly repeating bullshits stated by the authors:
<From wiki>

Systemd uses control groups to ensure that any service, regardless of its state, can be shut down properly.

Explanation: this is impossible and/or dangerus - Yes, systemd can kill each service easily, very much like the "WaitToKillServiceTimeout" setting in Winblows. It's a total bullshit or simply a lie that it's safe to "shutdown a service regardles of its state"

This. Aside from one poster above, everyone who has been on the side, or at least still on the fence about Systemd just reposts exxagerations or misleading information directly from the Systemd website. First, it was boot times. Now, it's cgroups and process shutdowns.. Really?! How stupid is that? Like this can't be done - at all - on Wheezy, as is, right this very millisecond?

Please folks, stop drinking the Systemd coolaid. It quite litterally does nothing that can't be done right now without it. Yes, Lennart and crew have done something interesting with Systemd, I will not deny it is has some interesting ideas contained deep down within the mess it is now. Yes, Lennart and crew at the very least are trying to do ~something~. My belief is that what they are doing does not have the best interests of computing freedom in mind, especially considering it leaves the BSDs out in the cold and breaking POSIX.

[confuseling]

What? That comes from the Debian wiki.

It's been pored over by the tech committee. Do you think any of it is wrong? Which parts?

[buntunub]

What? That comes from the Debian wiki.

It's been pored over by the tech committee. Do you think any of it is wrong? Which parts?

I did not say what is on the Debian Wiki is wrong. What is mostly on the Debian Wiki from what I can tell is a copy/paste off the Systemd website though, and while that is not wrong either, it is misleading.

For example, I can tell you that the sky is blue. In truth, it is not really blue in truth though. By touting fast boot times and easy process management, people just read that and say, "Hey! I get faster boot times with Systemd!" This is simply misleading and perhaps not even a true statement in light of the fact that other init systems are more than capable of fast boot times.

[confuseling]

How is it misleading? Be specific.

[buntunub]

How is it misleading? Be specific.

From above,

For example, I can tell you that the sky is blue. In truth, it is not really blue in truth though. By touting fast boot times and easy process management, people just read that and say, "Hey! I get faster boot times with Systemd!" This is simply misleading and perhaps not even a true statement in light of the fact that other init systems are more than capable of fast boot times.

Now let's look at process management. With cgroups you can do some interesting things in terms of managing processes. Is Systemd the only way this can be done? There is no other way to kill processes easily?

Sure, one can say that XYZ app can do XYZ and frame it in such a way as to make it sound like it is ~the~ answer to the worlds problems. Of course, this is not true. Ergo, misleading.

A true statement about Systemd boot times is:

"Systemd is capable of fast boot times, just like several other init systems."

[anastasis]

I'm just going to pipe in very briefly. Just ignore me. I'm not even here.

However, this is not even about a technical consideration.

Having a load of init donkeys doing all kinds of fun and happy things like slicing bread and delivering pizza might in fact be the way forward.

I have nothing against Harry Potter or his projects. I'm sure he can be an amiable enough lad when he wishes to be.

The problem here is purely political. Yes, I know that the easy thing is to say, Hey, let's keep the politics out of it. But that's exactly the problem. It is a purely political resolution. And it's a stupid resolution at that.

Perhaps systemd really is the Supreme Init. That's all great. But jumping out of an airplane while testing out a flight suit doesn't mean you should leave an old fashioned parachute behind, because we KNOW that works. Requiring that all things (maybe even the kernel itself) revolve around systemd is disturbing.

You claim to be techs. You claim to put security and stability first. You claim to not be politically driven, but technically driven.

So why, oh why, is this move anything but technical?

Ian Jackson proposed a resolution that really WAS about technical considerations.

It got shot down in a blaze of glory too for no good reason.

If it were a technically driven movement, you wouldn't have to force anything. It would win on technical merit alone. Admins would adopt it willingly and enthusiastically.

No one had to tell the world that VLC was a superior media player. It just WAS superior and became a de facto standard naturally.

[confuseling]

So, if all major distros have adopted systemd apart from Slack and Gentoo, doesn't that indicate that people want the functionality it provides?

Have you heard of any user revolts in Arch, Fedora, SuSE?

buntunub: seriously? That's your objection?