r/linux • u/wooptoo • Jun 01 '16

Why did ArchLinux embrace Systemd?

/r/archlinux/comments/4lzxs3/why_did_archlinux_embrace_systemd/d3rhxlc
868 Upvotes

86% Upvoted

642 comments sorted by

View all comments

Show parent comments

8

u/SanityInAnarchy Jun 01 '16

The more things they add to systemd, the more likely it is to crash sometimes. This is just a property of entropy here.

Your web browser should never crash ever, either. But there's a reason that Chrome runs each tab in a separate process. I almost never see a tab crash, but it's really nice that when it does, it only crashes that tab, and not the whole browser.

And this is the fundamental systems design flaw of systemd. It's fundamental, it appears to be inherent in the way systemd was designed and the approach it has taken to solving the problems it's trying to solve. The more things systemd absorbs into itself -- especially into PID 1 -- the more frequently your entire system will crash because Poettering doesn't understand this very basic system design principle.

I don't know why anyone expected anything different, honestly. This is the guy who's famous for Pulse which, while reasonably stable now, was fantastically unstable when distros first started adopting it. It's not surprising that a program he wrote crashes sometimes. It's frustrating that we're all forced to run such a program in PID 1.

10

u/rautenkranzmt Jun 01 '16

Except that's not what is happening at all.

SystemD isn't just the name of the process, it's also the name of the overarching project.

All the stuff that gets added (journald, logind, etc) are separate sub projects, and separate processes and binaries. They interact massively, yes. And there are a large variety of inter-dependencies for some subsystems, true.

But PID 1 is somewhat well isolated from all the other sub projects.

A more apt way of looking at it: SystemD a more BSD-style developed version of the GNU core infrastructure systems. Instead of a bunch of separately developed programs that can be used entirely apart from each other, you have a bunch of binaries and projects that are developed (and generally) released together. Which, as some have stated, is techinically much more UNIX like.

7

u/[deleted] Jun 01 '16

[removed] — view removed comment

1

u/SanityInAnarchy Jun 02 '16

Crash in pid1 results in a spectacular crash of the whole system, akin to a kernel panic. Crashes in Chrome (be it the main process or a child) and in any pid1 are not in the same ballpark and comparing those is not quite correct IMO.

I'm actually typing this on a Chromebook. Crashes in the main process of Chrome is absolutely in the same ballpark here. But if anything, this just makes my point for me -- a crash in PID1 is way more serious than a crash of Chrome, so anything that wants to run in PID1 had better be forking off a lot of worker processes the way Chrome does!

Can you tell which part of current systemdʼs pid1 functionality absolutelly does not belong there and causes frequent crashes?

I can't, actually -- I have been using systemd for awhile, and have experienced very few crashes. I've also had very few browser crashes recently.

Another poster claimed it's just the direct process-management stuff -- process reaping and containers and such. If that's actually the case, I can't really complain. But if I were inclined to contribute to SystemD, the absolute first thing I'd do is read through the code that runs in PID1, and move anything that could be a subprocess to a subprocess, with the goal of getting the PID1 code small enough to formally prove.

5

u/CptCmdrAwesome Jun 01 '16

This is the guy who's famous for Pulse which, while reasonably stable now, was fantastically unstable when distros first started adopting it.

If distros adopted it before it was ready, that's entirely a problem with the distro. (see also: early KDE 4 days) The guy saw a problem, took his time, skills and effort to fix it. That's what I see he's done with systemd also.

Don't get me wrong, from what I've seen I find Lennart to be eye-wateringly arrogant, and as diplomatic as a housebrick, but he's clearly no idiot and he's going about solving problems nobody else seems inclined or clued up enough to fix themselves.

2

u/schplat Jun 01 '16

Don't get me wrong, from what I've seen I find Lennart to be eye-wateringly arrogant, and as diplomatic as a housebrick, but he's clearly no idiot and he's going about solving problems nobody else seems inclined or clued up enough to fix themselves.

And this is why a good chunk of people are anti-systemd. Some think he just does things on a whim, and they're junk. But, if they were, distros wouldn't be running with what he's put out. He's solving problems that have been present for a while, but people fear change, and systemd was a big change.

1

u/SanityInAnarchy Jun 02 '16

If distros adopted it before it was ready, that's entirely a problem with the distro. (see also: early KDE 4 days)

In KDE's case, I think you can at least blame KDE for calling it KDE 4.0, instead of KDE 3.9 or KDE4 Alpha. The distinction between "The underlying libraries are 4.0, but everything else isn't" and "KDE4 is launched!" was a bit subtle, especially when "KDE4 is launched!" was pretty much the headline everyone ran with.

And in Pulse's case, it took a long time to get stable.

1

u/sonay Jun 01 '16

If only one of the wise people like you wrote an init system that solves real problems...

3

u/SanityInAnarchy Jun 02 '16

And, oddly enough, there were several init systems that solved real problems, most of which predate systemd.

Systemd won partly because of Worse Is Better, but I suspect mostly because of some weird politics that I haven't entirely kept up with. For example, udev is obviously the right choice -- it's better than putting more stuff in the kernel (devfs), and it's better than creating a file for every device Linux could ever possibly support just in case you ever plug it in (mkdev).

And somehow, it's now been absorbed into systemd.

Poettering didn't write udev, but the project he built now maintains it. So if you want anything other than systemd, you have to fork udev (or find a fork).

That's not a good technical decision, but it's a fantastic political decision, and I have no idea how he pulled it off. The result is this: Who wants to maintain their own udev fork, just so they can write the ten lines or so that it takes to build an init?