Demystifying systemd - 2015 Red Hat Summit

Ben Breard — Senior Solutions Architect, Red Hat
Lennart Poettering — Red Hat

Red Hat Enterprise Linux 7 brings a modern approach to many elements of the Linux operating system. One of the most significant of these updates is the adoption of systemd, which gives admins and users a host of exciting tools and functionality.

In this session, you'll learn how to get the most out of systemd in Red Hat Enterprise Linux 7, including:
-How init commands translate in systemd.
-Converting legacy init scripts.
-Customizing service unit files.
-Resource allocation via cgroups.

[aaronvaldes]

1:54 What is systemd
8:43 Units
9:16 Locations
10:08 Managing services
13:18 Targets
14:45 cockpit - webui
15:20 sockets
19:24 timers
20:05 Customizing Units
22:43 Resource Management
29:03 systemd-cgls and systemd-cgtop
31:49 BlkIO
32:06 Converting Init Scripts
32:46 Most Important Explanation by Lennart Poettering
33:38 Unit File Layout
35:15 Journal
41:58 nspawn
45:10 RHEL 7.2
47:47 Additional Resources

[borgemd]

Fantastic presentation. Very informative. I'm excited by the possibilities!

[ricktroth]

Great talk. Truly wish I could have been there. Thanks, Jon Miller, for sharing the link. A good intro to our brave new world.

The good:
 + switch service name and start/stop (better args ordering with 'systemctl' compared to 'service')
 + breaking out of the 0..6 "run levels"
 + tighter resource controls

The not-so-good:
 + assimilating too many functions into one program
 + maintaining content (the journal) in binary form (rather than plain text) see below
 + an RPM/Yum "feel" to the whole design (INIT should be simpler)
 + deceptive claim of logging everything (what happens before SystemD?)
 + replacing non-flaws in prior programs

Switch from text to binary is security through obscurity.
Ask any security professional how secure that is.
Much better to push logging to another host for true "hands off".
And yet, "rsyslog" is still required?

There's a learning curve. No complaints there for true innovation. But some features of programs which SystemD replaces were not broken. Sad that we have to re-learn more than from simply adding a new package.

The presentation has some "ad-hominem attacks" on SysV INIT. In particular, the complexity of INIT scripts is not an inherent fault with SysV INIT.

Others may have reported similar experience: I had no serious delays in booting with SysV INIT. Ironically, I have had noticeable delays when booting with SystemD. Have not investigated why, but interesting since the most public claim of SystemD value is faster boot times.

It's no secret that I don't like SystemD.
Would like to think my objections are more pragmatic than knee jerk.
I honestly believe I would have no problem with it if I could select the traditional arrangement, so the frustration is with the distributors more than with SystemD per se. Wasn't that what we were all about in Linux land? the ability to choose?

-- R; <><

[lawrencedoliveiro]

19:28 I think one reason why people were so scared of systemd is how it unifies several concepts which were previously disparate in the *nix world--system startup, socket listeners (inetd/xinetd), timers (cron)--and puts them under a common architecture, amenable to common management tools. People complain this is “monolithic”. No, it’s just good sense.

[lawrencedoliveiro]

9:26 General rule under Linux: leave the stuff in /usr/lib, /usr/share etc alone!

[jacobsherman]

are the slides from this available somewhere

[amacinside]

Yes, thank you systemD for numerous bugs that have been returning over and over again since it's inception. I just LOVE seeing stuff like "a stop job is running for session c2 for user" and having to wait... and An init system that can't even shutdown
Thank you systemD for doing way more than it actually should but not doing it's basic function properly.

[CodyCrudgington]

Wrong, you can also clean up logs by size... not just by time.

[lawrencedoliveiro]

15:09 Cockpit is not Red-Hat-specific, it’s available in Debian too.

[BryanJonSmith]

_"the whole thing is monolithic" -- +Adam Thornton_

Pretty much *undermines* your entire argument.

Any time someone says systemd is _"monolithic"_ doesn't know the first thing about it. That along with _"it's designed for the desktop, not the server, "_ really gets old, especially considering the Red Hat customers -- even major, commercial Debian userbases (the reason why they wanted systemd instead of Upstart) -- that have long had requirements for these capabilities, in the base, single PID 1 program -- the *only* part that is "monolithic."

It's like saying Apache is "monolithic, " ignoring the fact that it has a very base program, then has many core, modular components, plus all sorts of optional modules, and yet others that don't even ship, but are under the Apache project.  There are exploits with Apache modules regularly ... but not the core Apache daemon itself, which is the only thing monolithic.

Same deal with systemd, only the init, PID 1 replacement is monolithic ... just like any other PID 1 program in *any* init solution. ;)

Even journald and other components that are highly recommended are modular, separate components, from the PID 1 program.  And then there are things that aren't even included by default, much less built in most distros ... but are in the systemd project.  Those are the things people go after ... and say it's "monolithic, " and just connect whatever dots they want, even if LP, Kay and others aren't even involved with those "contributions."

One of these days people will actually file bugs and point out relevant issues with systemd components ... instead of this age-old, quite heavy *FUD* that just doesn't die (and it needs to).  In fact, if the anti-systemd folk have succeeded in doing anything, they've managed to proliferate the same, lack of knowledge that infects others, and prevents people from actually learning it.

Which is why most people who are systemd knowledgeable, just like they are Upstart knowledgeable, just end up ignoring the _"SysV init-only, it does one thing and does it well!"_  SysV doesn't, and virtually all other UNIX implementations have already stated so too (in fact, LP hits on most of them in the first 10 minutes). But we don't have to agree with every LP, Kay or other comment or argument to see what systemd is really trying to address, that enterprises use.

But then again ... people didn't learn PulseAudio either, thinking PulseAudio wasn't needed (not realizing all of the features that ALSA doesn't offer), and then blamed PulseAudio for issues that were a single, distro-specific implementation issue (and not PulseAudio at all).

[unixbhaskar]

Good to know nspawn  getting better feature.

[Xcelleratr]

Systemd is good as an option, but the dependency of far too many systems on systemd is very concerning to me. There are way too many eggs in one basket, if the basket breaks, a lot of linux users are in trouble. All the distros left that don't use it are either obscure or not considered "user-friendly" (like Void and Gentoo). Again, as *one* option I don't mind systemd, but I don't like that its practically the only option.

[thirdeyeblind]

Thanks Lennart for giving blackhats a massive gaping attack surface. What a guy!

[xpkareem]

I've never heard anyone refer to /etc as "etsy" before. Took me a sec. Great talk tho.

[endoscopisis]

I see all the comments below saying that systemd is crap but no one is actually saying why. So here I am, asking that question to all of you.

[JuusoAlasuutari]

Cockpit, eh? Do you like movies about gladiators?

[gregoriodia]

"So we made this huge-as-elephant thing in systemd called "nspawn" - we do not know what is good for ("if anybody has use cases for it let us know") but we will force that on everyone again - like you know "f*** those people who like their OS to only do as much as it has to", let's just force networking into init system - because that is what we do - we are Lennart, we are German, we know better, we force things on people like our grandparents did in 1939 - because that has worked so well for the whole world so far.
I am not against existence of systemd - I am against FORCING on people something that is WRONG to begin with, init system should do just that - INITIALIZE.

[kalelalves]

hahahahahahahahahahahahahahahahahahahaha, that funny to rear just after see a systems hangs for almost two minutes just for a DHCP to boot...
oh yeah, try sell that, and this is almost 2 years latter

[MrBraffZachlin]

long story short systemd is involved in too many things. lets just make linux windows while we are at it

[sgny]

Systemd is crap! I will never understand, why a company like Red Hat would see a need to change to that crap for their system. Linux is going down the Windows way.... not much difference anymore.