Slashdot Mirror
Torvalds: No Opinion On Systemd
An anonymous reader writes:Linux creator Linus Torvalds is well-known for his strong opinions on many technical things. But when it comes to systemd, the init system that has caused a fair degree of angst in the Linux world, Torvalds is neutral. "When it comes to systemd, you may expect me to have lots of colorful opinions, and I just don't," Torvalds says. "I don't personally mind systemd, and in fact my main desktop and laptop both run it." Torvalds added, "I think many of the 'original ideals' of UNIX are these days more of a mindset issue than necessarily reflecting reality of the situation. There's still value in understanding the traditional UNIX "do one thing and do it well" model where many workflows can be done as a pipeline of simple tools each adding their own value, but let's face it, it's not how complex systems really work, and it's not how major applications have been working or been designed for a long time. It's a useful simplification, and it's still true at some level, but I think it's also clear that it doesn't really describe most of reality."
Sounds good. What is it again? :reasons:".
I clicked links. Looked at the article. They all talk about systemd but none really define it, as in "systemd is this and does that, and is different because
So for any other systemd-impaired readers, click this: http://en.wikipedia.org/wiki/S... - because TFS, TFA and links from them don't tell you much in this regard.
...gis sdrawkcab (usually not responding to ACs; don't bother posting as AC)
If they're going to change it, I suggest they change it well.
That is, support *functional* dependencies between processes, and caching of input/output. Automatic starting of processes when configurations change, etc. Right now, my computer has to reboot whenever stuff changes and some script does not handle the changes correctly (or simply does not run).
Also, whenever I reboot my system, I don't know if I will get back the system that I shut down (some configurations may have been changed and may have broken my system without me knowing it, only to cause a nightmare when I reboot the system, which is usually the worst possible moment). That has to be fixed as well.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Now, the real question one should ask Linus is whether he trusts systemd upstream's "taste". The answer will be nowhere near as nice.
The major issue with systemd is actually that we don't trust its upstream. They're known to cut (important!) corners since well before systemd (i.e. pulseaudio), and they have the "we know better" mentality.
The last time Linus had to trust systemd to do something (udev component), it caused a massive (and deserved) flamewar which ended up with the kernel removing support for udev's firmware loader, and switching to an in-kernel firmware loader to bypass udev.
I think he just doesn't care about things that don't get in his way.
A few weeks ago, when systemd would lock up the system if you turned kernel debugging on, he did have rather colorful opinions about systemd and the systemd developers who insisted that systemd was doing the correct thing.
The argument is that, if pid 1 dies, everything dies. Also a big pid 1 presents a big attack surface for nasty people.
Of course the exact same argument applies to a kernel: if something goes wrong in the kernel, everything dies and a big kernel presents a big attack surface to nasty people. However, I observe Linux is not a microkernel but it has a reputation for both reliability and being relatively secure. On the other hand, the quality of the people developing the kernel seems to be higher than those developing systemd, or at least that is the perception I get from reading all the hate on the Internet.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.
Lifting which should not be done by PID 1. And PID 1 has to be more complex than it should be just to handle those external programs.
SystemD currently does a fuckton of stuff no other currently usable init system on Linux does.
It does a lot of stuff the init system shouldn't do.
(Reliable process supervision which cannot be evaded,
cgroups existed before systemd.
sane handling of process stdout/stderr
Up to the init script.
proper handling of dependencies at runtime
Already handled by several init systems.
socket activation
We call it inetd.
I don't particularly care which init system my system runs, but I want those features and currently only SystemD can deliver them.
That is ignorance at best, or perhaps a lie.
Please stop spreading FUD about things you know next to nothing about.
You have no idea about anything, that didn't stop you. I see why you didn't log in.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
You can't seriously claim that systemd provides nothing that can't be done by script based init systems, shell scripts and existing daemons
Yes, yes I can. And I did.
logind is just one example
Does nothing a script can't do
But it would be an interesting project to make a Linux SysVinit distro that tried get feature parity with systemd, so that daemons could utilize the kernel "namespaces" and "capabilities"
Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.
Isn't that argument just trying to make a virtue out of the fact, that SysVinit and the like, are totally crude and primitive init systems that are unable to anything much of interest?
No. That is the virtue. They are simple. Simplicity is still a virtue.
All the analyses I have seen shows that moving crucial processes into PID2, just makes everything more fragile and opens up security holes.
Making PID1 more complex makes everything more fragile and opens up security holes.
I think that there are actually very good design reasons for why systemd is designed like it is.
NIH
It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,
This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Xorg, which on desktop is as critical as init to keep running, is not really simple.
Never go full retard. X is not even remotely as important as init. For one thing, if X dies, who will restart it? And do we really want computers that explode when the GUI dies? I, for one, would like network services to terminate gracefully. The whole idea of TCP/IP networks, the dominant network used with Unix, is peer-to-peer. I may well run both services and clients on my machine. If X dies, the clients may die (if they're not text and running in screen) but the servers won't.
kernel, which is also as critical as init to keep running, and it is *much* *much* more complex than systemd. systemd is not at the "bottom layer" of the system, there's the whole of kernel underneath still.
So the argument is that since the kernel is complex, we should add more complexity, or that more complexity won't matter? That's an ignorant, illogical argument.
And one common myth is that systemd has these so many features and systemd is pid 1 therefore pid 1 is this huge bloated monster that does udev, logging and NTP, right? Wrong; actually, just the core bits of systemd run in pid 1 and the rest is compartmentalized in a bunch of separate daemon processes.
Systemd still has to be more complicated so that it knows how to run these other processes, which wasn't even necessary. init was never meant to manage daemons. daemons were meant to manage themselves, or be run from inetd. If you want more complexity, inetd is the place to add it. And for handling daemons which don't adequately manage themselves, there's daemontools. There was simply no need whatsoever for this to happen.
So, this "increased complexity" issue is not really as bad as it sounds, realistically.
It is bad, because PID1 is now responsible for a bunch of things which could have existed in any other daemon. And rather than roll the things which actually make sense in together, everything is getting rolled together. So now not only do we depend on a complex kernel, but we depend on a needlessly complex init system. There was no good reason to put all of this stuff into the same daemon.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
logind is just one example
Does nothing a script can't do
Do you really think it is a serious argument is that you could re-implement "logind" as a bash script? We are talking serious hardcore system stuff here, which is why no-one have made an alternative to "logind" or "ConsoleKit" despite upstream projects have pleaded for such a program for several years.
Systemd doesn't even fucking use capabilities, just cgroups. Which we could use before systemd. Systemd manages permissions in lieu of using capabilities, e.g. apparmor or selinux.
You are seriously misinformed on how systemd works and what it can do:
It uses kernel namespaces and capabilities to protect the system; this is on top of SELinux etc.
Here is a general overview:
http://0pointer.de/blog/projec...
Here are some of the config options for the daemons you can use. See "CapabilityBoundingSet=" for one way of using kernel "capabilities":
http://0pointer.de/public/syst...
There are so many freaking cool security features in systemd. As time goes by, developers, distro maintainer, and systemd administrators, can add more and more options to the running processes, like "NoNewPrivileges=" to prevent privilege escalation, or "ProtectHome=" to prevent malware and exploited processes from stealing info from /home, even if they otherwise had permission to read in home.
All this great new stuff can be turned on and used by adding a simple keyword to a structured text file. As time goes by, systemd distros will become ever more hardened.
It only runs one process as PID1, the daemon "systemd" which is rather small. This daemon however, is capable of "talking" with with several other processes, which gives it many advantages,
This is making init do stuff it doesn't need to do, which makes it more complex, which makes it more fragile. You should not need a detailed explanation to understand why this is a bad thing.
Well, it does need to be handled somewhere; if you want features, you will get complexity, it is that simple. But as explained, the features and complexity isn't running in PID1; PID1 (systemd) is just a hub for relaying those features to other processes.
I really think so much of the systemd opponents talk about "Unix way" and "PID1" should be simple, is hand waving to gloss over the fact that the non-systemd distros have no feature parity with systemd to speak of; SysVinit is crude and no one in their right mind would design a init system these days with executable config files. Service configuration files should be non-executable text only.
General and vague criticism against systemd really doesn't convince anybody. Anyway, the Linux community have spoken with a large majority of Linux distros using systemd in the future.
If SysVinit systems really have all the features of systemd, just much better because they are simpler, you would expect a "SysVinit" boom in the future with lots of developers and users.
Personally, I think the systemd opponents are too concerned with negative campaigns against systemd, that they entirely forget to code any alternatives, so I predict ever more distros like Slackware abandoning script based init systems; they simply don't have an alternative.
You don't seem to understand how SystemD actually works. The PID 1 is relatively simple -- it uses all sorts of separate (i.e. non-PID 1) helper processes to do all the heavy and complicated lifting.
And another thing I like about systemd:
- it groups into 1 single project: 1 single task (starting-up/seting-up things) that was spread accross way too many different project before.
Before systemd:
Want to start a service during boot-up ? Put it into sysvinit. Except if it's a file system, then it goes into /etc/fstab. Or if it's not a *service* but like of an interface like your terminal that should go into inittab (Except on distribution which do THE EXACT SAME THING but in init.d anyway).
The thing which start is related to actual hardware? the you need to put it into hal, no way we replaced that with udev... except that a few distro put them any way in init.d and thus your hardware might not work when plugged after booting... unless you also duplicate some code into modprobe.conf's post-runs.
And what if conditions for your code to start isn't "boot-up" nor "plug-in" ?
Then put it into inted/tpcd if it's network triggered. Except for code that doesn't work there, because the service needs to be compiled to use libwrap to work this way. So then you'll have to run the service constantly and fumble around with ip filtering to enable/disable it on demand.
Or put it into cron if it's time triggered.
And you need to start a service and the periodically monitor it for failure, and restart and raise alert if it has failed? Well either use an entirely separate custom system like djbdns's daemontools. Or write your own monitoring solution by writing a ton of scripts which tap into all those different ways to start/stop stuff and hope that it works.
And don't get me started about initialising containers (limited fonctionnality, tons of script), brokering access rights around (not really used. lot of interface must run as root and drop privileges, or lot of interface must be world accessible), handling situation as missing configuration or drivers in a system that hasn't fully booted up to the point where the GUI works and the user can fix things from here (huge tons of scripting to achieve way to detect that Xorg is failing and to propose solution to fix drivers)
All this written in shell script which can have their own pitfalls, and every single system using a different syntax.
After systemd:
PID1 and its herd of helpers take care of setup/start/stop/teardown.
Want to do *something*? Write a systemd config file, and describe which trigger (boot, after another service has started, on network, by clock, on device plug, etc.) should start it.
You can even call legacy systems from within systemd (cron can be reimplemented as a systemd service that runs periodically and reads/executes crontab, etc.)
You can have an LXC that is quickly setup. In fact you can quickly create throw-away container to jail any service separately (systemd is the kind of infrastructure that can boot a dedicated LXC jail to run Skype into, with restriction correctly setup so that no hidden backdoor could spy on you).
You can have systemd handle brokering the necessary rights (to the point that plugin an USB stick and having the currently active user access to it isn't a nightmare anymore).
If anything the handling of setup/startup/stop/teardown WAS NOT "unixy" before, it was "have 384 different programme which all do a different part of one single task in subtly different ways".
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
(Reliable process supervision which cannot be evaded,
cgroups existed before systemd.
the cgroups functionnality existed in the kernel but wasn't really used that much before. /etc/init.d/apache can't without fumbling of shell scripts.
systemd, with its tasks in setup/startup of things can handle the creation of jails during lauch when needed.
whereas current
sane handling of process stdout/stderr
Up to the init script.
And thus each script end up fucking things up in its own original and different way.
proper handling of dependencies at runtime
Already handled by several init systems.
None of which are the original sysvinit.
Either it's relying on LSB-extended script and a different core which starts the scripts. (Debian had a makefile based one)
Or it's an entirely new system anyway like upstart.
socket activation
We call it inetd.
Or cron if it's time-based activation. Or udev if it's hardware based activation. Etc.
Why do we need 83 different way to start some code ?!
Wasn't the whole point of Unix philosophy having one piece of software which concentrates into doing one thing and doing it well?
With systemd, setup/startup/stop/teardown responsibilities are concentrated with PID1 and it's helpers.
Before, you'd have the same concept spread into a dozen of different systems, each only doing part of that functionnality.
I like systemd, it makes my work easier on desktop, on server, on virtual machines, etc. and although it used to have hiccups when it was introduced before in opensuse, by now it has had the time to mature.
no need to bash it. if you don't like it, don't use it.
and perhaps the fact that it's slowly gaining popularity in lots of mainstream distro might be due not because systemd is "a spreading cancer" but because systemd is actually useful and solves real world problem
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
I've been a sysadmin for 20 years, and I've seen systems break in lots of interesting ways. What I want is a log mechanism which is as simple as possible so that it as least has a chance of giving me the info I need even if the rest of the system is in the process of going to hell.
What I don't want is an unnecessarily (you aren't even able to explain the advantages, actually some of your "advantages" are disadvantages like the corruption detection) complex system which will take ages to debug, IF it will ever be - most software is already too complex and too fast moving to be ever debugged sufficiently. It violates the KISS principle. And the advantage of Linux over Windows used to be the KISS principle...
systemd's logging facilities are superior to old syslog in several ways. Fx. systemd and journald lives in initramfs while the system is booting, so it can collect logging info from before the root fs is even mounted. Since systemd actually have knowledge about mount points and files systems, it can also delay to the very last moment the things needed for journald to write to the log.
There is also kernel guarantee that the daemons/pid's/programs that appear in the log are the real ones since systemd have total control and supervision of all processes. So if "lp0: printer on fire" appears in the log, you will know whether it is a prank or a real message.
The structure and index makes it possible to store lots of interesting meta-data, like monotonic time-stamps, GUI, PID, command line, marks from where every boot started and ended ("journalctl -b -p err" shows all loglevel "error" messages generated last boot only). Using monotonic timestamps to compare two boot sequences on perhaps two similar machines, is quite interesting and very easy to do.
It also allows for multi-language log support, supplementary help files that can explain what the error message means, suggest how to solve the problem, etc.
Here is a list of fields in the journal. Because of the index, the journal have real time knowledge about what is written in the fields, so there is tab completion and extremely powerful sorting available:
http://www.freedesktop.org/sof...
If you care about logging with systemd, take a look a the original design document behind journal
https://docs.google.com/docume...
Notice how simplicity is design goal number 1.
If you intend to remain (a paid) Linux sysadmin in the future now where all major distro are starting to convert to systemd, you should really study systemd's journal.
It is much easier to "get" the power of a indexed and structured log file by trying it, than describing it. Fedora 20/CentOS 7 are reasonable choices to learn it on.
check out systemd's "nspawn" too: OS containers really are the future.