Demystifying systemd - 2015 Red Hat Summit
HTML-код
- Опубликовано: 2 июл 2024
- 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. 
Наука
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
Fantastic presentation. Very informative. I'm excited by the possibilities!
man this was really useful. +1
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;
I am going to enjoy my schadenfreude when--and I predict this happens within the next fifteen months--there is some huge, horrible remote exploit against systemd that is really, really hard to remediate because the whole thing is monolithic and whatever is wrong is not a bug so much as a fundamental design flaw.
The entire point of the Unix way of life is a bunch of small sharp tools, each with a single function, that you can compose using pipes. And yes, I say that and my editor of choice is Emacs.
Systemd is exactly the opposite of that.
The inherent flaw of SysVInit is just that dependency management is purely conventional, and the classic way (the two-digit priority in the name) is dumb and fragile, and the more modern way (parsing magic comments in the initscripts) is *also* dumb and fragile.
But, you know, there are probably ways to be able to specify proper dependency ordering (and therefore, implicitly, to decide what is parallelizable) without allowing the Borg to assimilate your entire system.
I put together something on VM a bunch of years ago, using GLOBALVs, to do that. I called it "Sysvinit," which was a bad idea, especially since by the time I was done it actually had a dependency graph. In fact it's still up there: www.sinenomine.net/products/vm/s5i
This wasn't especially elegant, but it solved the problem of "I want to start i, j, k, l, m, and n. m depends on l, which in turn depends on j. n depends on k and j." Generating that graph is really the thing you need in an init system. Now that everything is multicore/multiprocessor, parallelizing the things you can is nice too.
Note that that does not need binary logs, or an internal DNS server, or ....
narf-archive.com/pix/bd0fb252416206158627fb0b1bff9b4779dca13f.gif
Adam Thornton, I expect your prediction will pan out, unfortunately--it just feels like this ambitious juggernaut is moving forward too aggressively to shake out the truly nasty gremlins before widespread deployment has already occurred. The hubris is extraordinary, and everybody has heard what precedes falls. I do not want to have to deal with it when it happens,
but I'm beginning to wonder just how much significant infrastructure is exposed already, and that exposure has to be growing. I sure hope we're wrong.
I've been happy with openrc (gentoo). Named runlevels, easy depends, provides mechanism. It is a evolutionary step from SysVInit.
xxsdaktr
Good to know nspawn getting better feature.
9:26 General rule under Linux: leave the stuff in /usr/lib, /usr/share etc alone!
Hmm
Oops...
slides somewhere?
are the slides from this available somewhere
www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&cad=rja&uact=8&ved=0ahUKEwjG6buhxozUAhUC94MKHbofBvEQFghIMAU&url=http%3A%2F%2Fcd-docdb.fnal.gov%2Fcgi-bin%2FRetrieveFile%3Fdocid%3D5509%26filename%3DLinuxAtFermilab-2015-07-demystifying_systemd.pdf%26version%3D3&usg=AFQjCNGvrNd2VUGtPZar57VHRkwFi8Unsw&sig2=ygk7Xxlp7PLdQKnjMJ4QPA
you are a god among men
Wrong, you can also clean up logs by size... not just by time.
15:09 Cockpit is not Red-Hat-specific, it’s available in Debian too.
It's all true. No doubt.
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 wait..... An init system that can't even shutdown properly......
Thank you systemD for doing way more than it actually should but not doing it's basic function properly.
Im using debian sid with thousands of packages, absolutely ZERO problems with System-D... also no problems on my arch install...
Take care everyone.
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.
As a Linux sysadmin, I say Systemd is an absolute mess. It's trying to do too much, too fast, and has caused all types of expectations of a Linux system to break. Scope units get SigHUPd and often SigKilled on shutdown by default, which leads to network applications not properly tearing down connections on shutdown. The ordering of the dependency graph is non-trivial to get right, the tooling has bugs. coredumpctl will itself coredump/crash if the actual process that is dumping core has an empty environment.. Do to (what I presume is due to ) sloppy backporting, often the man pages have diverged from the actual functionality.. so many issues.
_"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).
I've never heard anyone refer to /etc as "etsy" before. Took me a sec. Great talk tho.
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.
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.
without-systemd.org/wiki/index.php/List_of_articles_critical_of_systemd
For a simple reason. The average Unix machine runs 1-2 years nonstop. There is no reason for a "fast boot" and unreadable binary logs. When you change hardware or compile a new kernel, it is enough to restart daemons by hand and check they run as intended by taking looking into the log files, and then start the next service. It does take some time, but if something does not work as intended, you want to take a look why that is and solve the issue before starting more stuff. Since you do that in average only once every 1-2 years for a machine, there is no reason for to have this systemd nonsense in memory consuming electric power for nothing. And recycling a daemon can be done by atrun/cron from time to time, it doesn't need some additional processes on top. So why have this? There is certainly reasons NOT to have it, and that is unreadable log files, since they are kept in binary, memory and power consumption, and the additional cpu load, that no matter how little it would be still is a pointless waste of electric energy that sums up over time. That is the most simple reasons, besides with all the additional issues that come along with this thing ...
Thanks Lennart for giving blackhats a massive gaping attack surface. What a guy!
Cockpit, eh? Do you like movies about gladiators?
Have you ever been to a gymnasium?
DN3D > systemd.
.* > systemd
Lol systemd is the best. Punk ass bitches hating on him.
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
"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.
No one is forcing anything. The reason distros choose systemd because it's superior to sysv and the rest. That's the cold truth. The systemd itself is very small and all that stuff is just modules. Now, systemd could be crap (I think almost everything in Linux plumping is shoddy garbage compared to Windows or Android), but at least it's an improvement over sysv or upstart.
Btw. Germany didn't force anything in 39. The polish corridor was stolen from Germany and given to the Poles twenty years before that. The stupid idiots in school say the same thing about Spain when the Spanish were brutally conquered and sold into sex slavery. But they became the bad guys when they were trying to take their own country back.
+Garegin Asatryan "Germany didn't force anything in 39."
i1.kym-cdn.com/photos/images/original/000/131/351/eb6.jpg
"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. "
From where comes this hate?
I was born at 1962, and my surname is Stettin.
Who cares?
Calm down, sister or brother!
Thorsten Stettin From Polish dude who have had it with forcing "refugees" without any verification on everyone around. How well it goes we have all seen in Cologne nev years eve and all the crime rates in countries who neglected verification of these people before letting them into our house (EU), all these bombings etc.
So yeah - the only obstruction for the peace in the world seems to be Germany...
long story short systemd is involved in too many things. lets just make linux windows while we are at it
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.
Whats a better alternative?
FreeBSD / TrueOS
4:59 cgroups are a Linux-specific feature. So reliable killing of daemons, as systemd offers, is only available on Linux.
Corporate interests are not the same interests that the community has. As more and more corporations move into Open Source (Micosoft) and get interested in Linux-Distributions they will push their own software designs and thereby philosophy onto those Distros. FORK!
Lol at linux going down the windows way. You are going to have to explain that one.
its the cancer of linux
Crappy software designer. Thanks for nothing.
CrapD