Why systemd? • Hacker News Board

Re: Why systemd?

#191

Post by oftenwrong » Tue, Sep 23, 2014, 2:13 PM UTC

clarry wrote: post #145

e12e wrote: post #139

Earlier quoted context omitted.

Reminds me of the joyful early days of moving from grub to lilo. Grub was (is) more fragile due to being more complex -- but at least the grub shell gives more information than lilo failing at "LI"... Grub always seemed like the improved features made up for the added complexity; I'm not convinced about systemd.

Even Grub isn't all flowery. I have a background of using what I think is now called grub-legacy. Then I ended up running Debian, with newfangled Grub. I needed to change some kernel parameter (IIRC) but all I could find was a mess of undocumented scripts which say "don't touch this". I don't know where the documentation went, and it seemed needlessly complicated to configure. Why couldn't I say man grub and learn al…

    info grub

Re: Why systemd?

#192

Post by makomk » Tue, Sep 23, 2014, 2:14 PM UTC

andor wrote: post #184

makomk wrote: post #174

Earlier quoted context omitted.

The systemd developers are planning on replacing dbus with their own NIH reimplementation, kdbus, soon - complete with its own serialisation format, its own in-kernel IPC framework, and a hard dependency on systemd. (Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too.[1] That library currently supports old-style dbus but they're planning to drop support for that,…

Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too. Have you actually read the mail you're giving as "evidence"? The last paragraph begins with: "The current idea is that systemd will provide a bridge service, that offers the current D-Bus socket, and an unmodified libdbus (or an alternative implementation) can talk to that socket like it talks today to the dbus-d…

Okay, correction/clarification: it requires everyone to rewrite their code if they want to use kdbus rather than doing old-style dbus calls to the compatibility daemon, which may not be installed by default and is a fairly ugly hack that's probably going away in the future. It needs a bunch of special support code in systemd that's not used for anything else, and the generall expectation seems to be it's a stopgap and most or all dbus consumers will move to kdbus.

Also, technically developers don't have to use systemd's dbus library; apparently Gnome's doing direct calls to the kdbus kernel API instead. That makes it even harder to support systems that don't have kdbus+systemd, of course, but this is Gnome we're talking about.

Re: Why systemd?

#193

Post by cbsmith » Tue, Sep 23, 2014, 2:21 PM UTC

tankenmate wrote: post #190

cbsmith wrote: post #84

Earlier quoted context omitted.

> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infra…

You need to double fork() in order to ensure that the daemon won't be the controlling owner of the tty once it calls setsid(); i.e. that it will be re-parented to init. So personally as a sysadmin that occasionally runs daemons from the command line I much prefer a double fork(); I don't want the daemon to exit when I log out.

Yeah, I think we all know why the double fork model exists. It turns out, if fork a daemon from a different process than your login shell, you don't have a problem and you can more reliably track the process...

Re: Why systemd?

#194

Post by cbsmith » Tue, Sep 23, 2014, 2:23 PM UTC

makomk wrote: post #192

andor wrote: post #184

Earlier quoted context omitted.

Oh, and it requires everyone to rewrite their code to use systemd's dbus library rather than libdbus too. Have you actually read the mail you're giving as "evidence"? The last paragraph begins with: "The current idea is that systemd will provide a bridge service, that offers the current D-Bus socket, and an unmodified libdbus (or an alternative implementation) can talk to that socket like it talks today to the dbus-d…

Okay, correction/clarification: it requires everyone to rewrite their code if they want to use kdbus rather than doing old-style dbus calls to the compatibility daemon, which may not be installed by default and is a fairly ugly hack that's probably going away in the future. It needs a bunch of special support code in systemd that's not used for anything else, and the generall expectation seems to be it's a stopgap an…

So basically the horror you're campaigning against would be... change that provides full backward compatibility?

Re: Why systemd?

#195

Post by dalias » Tue, Sep 23, 2014, 2:23 PM UTC

cbsmith wrote: post #96

dalias wrote: post #85

Earlier quoted context omitted.

Whether it's all in pid 1 or not is irrelevant. What matters is that it has a monolithic architecture, whereby breakage in any one part or their communication channels can bring down the whole system. This is not just a theoretical concern; it has REPEATEDLY happened.

> Whether it's all in pid 1 or not is irrelevant. All of the existing mechanisms are also a "system" that compromises a ton of processes... If systemd is monolithic on these grounds, then so are they. > What matters is that it has a monolithic architecture, whereby breakage in any one part or their communication channels can bring down the whole system. Uh-huh... I think you are speaking to branding more than technol…

Systems which do not use systemd simply do not have these problems because there is no analogous component. If syslogd goes down, the worst that happens is you don't get logs. Init doesn't go down because it essentially has no inputs. Individual services can go down if they're poorly written, but they won't bring the system down with them. Traditional systems (the hideousness that is "sysvinit") have plenty of other different problems (e.g. race conditions in process supervision), but deadlock or bringing down the whole system is not one of them.

With systemd on the other hand, all of the components under the systemd banner are tightly interconnected and communicating. In particular pid 1 has ongoing communication with multiple other components, and misbehavior from them can, both in theory and in practice, deadlock the whole system. In case you missed it, this is roughly what "monolithic architecture" means: even though the components are modular, they're designed for use in a tightly interwoven manner that's fragile. It's completely the opposite type of "monolithic" from the kernel, which has everything running in one address space, but with architectural modularity, where interdependency between components is kept fairly low.

Re: Why systemd?

#196

Post by uselessdguy » Tue, Sep 23, 2014, 2:26 PM UTC

cbsmith wrote: post #83

uselessdguy wrote: post #51

Disclaimer: I develop uselessd, probably have a warped mindset from being a Luddite who values transparency, and evil stuff like that. The author of this piece makes the classic mistake of equating the init system as the process manager and process supervisor. These are, in fact, all separate stages. The init system runs as PID 1 and strictly speaking, the sole responsibility is to daemonize, reap its children, set t…

> To stuff everything in the init system, I'd argue, is bad design. You've slayed the straw man... ;-) systemd doesn't put everything in pid 1. It defines some mechanisms to orchestrate the whole thing that include pid 1.

I wasn't talking about systemd, in particular. I was using a hypothetical example to counter the OP's point. That said, systemd's main.c still does have significantly more baggage than most other systems I've seen (never looked into Solaris SMF internals, for instance).

Re: Why systemd?

#197

Post by dalias » Tue, Sep 23, 2014, 2:29 PM UTC

vidarh wrote: post #162

edwintorok wrote: post #149

Earlier quoted context omitted.

I think the ideas presented in the 's6' init system address most of these issues, I don't know why none of the distributions picked it up as an alternative: http://skarnet.org/software/s6/why.html http://skarnet.org/software/s6/s6-svscan-1.html

It doesn't address the logging issue, as far as I can tell. It appears to rely on the same logging solution as the original daemontools. I used daemontools extensively for a while, and it was great, and I like Bernsteins design philosophy which appears to have been largely carried forwards into s6, but it was simplistic, and suffers from a number of the same problems as a "raw" SysV-init, such as putting us back at t…

People actually _want_ the logging behavior of systemd? My impression is that it's the most widely hated part; I've heard endless stories of journald thrashing the filesystem forever, losing logs completely on corruption, etc. And even operating properly, its performance is comparable to grepping a flat text log, since despite having a "more efficient" format, it increased the actual data size by something like 4-10x.

Logs are essentially write-once, write-often, read-rarely data. As such, the optimal format is always going to be a flat, append-only file.

Re: Why systemd?

#198

Post by xenophonf » Tue, Sep 23, 2014, 2:30 PM UTC

albertzeyer wrote: post #128

clarry wrote: post #101

Earlier quoted context omitted.

Yes, modern linux and sysvinit are pigs compared to some alternatives (though systemd is worse). The choice isn't a binary choice between sysvinit and systemd. How about this? init + rc + all the scripts combined are smaller than your handful of daemon-specific scripts. And I understand exactly how all of this works (the kernel parts included). I can easily change any part of it, I can easily debug any part of it, I…

I think you also need to count the Bash source code there.

You cannot assume that /bin/sh always refers to Bash. There's a lot more to Unix than just Linux and Mac OS X. On FreeBSD /bin/sh is a 1989 rewrite of the SVR4 Bourne shell. As of 10.0-RELEASE it comes to 21167 lines, including its Makefile, ancillary shell scripts, and documentation.

Re: Why systemd?

#199

Post by dalias » Tue, Sep 23, 2014, 2:34 PM UTC

exDM69 wrote: post #141

dmix wrote: post #88

Earlier quoted context omitted.

I appreciate your work on uselessd. Nothing demonstrates a counterpoint quite like written code. The last thing we need is another ranting systemd blog post. We always need strong alternatives, even if they face the risk of being taken as simply a political statement, the effects of the statement will be seen in the decision-making down the road.

Yes! What the systemd "discussion" has been missing is viable alternatives that are somewhat comparable in features. Most of the flamewar is focused on people who consider the problems that systemd tries to solve non-issues. There are some real issues being pointed out (particularly regarding monolithic design) but no-one has attempted to actually fix that in any way (in code, that is). While it is unlikely that I wi…

There are plenty of viable alternatives: s6, runit, OpenRC, and so on. I'm not really convinced uselessd is a viable alternative - it keeps way too much of the badness of systemd, but I guess that makes it viable if you were willing to consider systemd to begin with.

A much better solution for the problem of user-facing applications (e.g. "desktop environment" software) depending on systemd's public dbus interfaces is to provide a fake service that gives them fake data - the same way you would sandbox Android apps for privacy by giving them a fake Contacts list, etc.

As for the other main "public interface" of systemd that things are starting to depend on, the systemd service file format, it would be easy to add support for this file format to any other process supervision system.

Re: Why systemd?

#200

Post by dalias » Tue, Sep 23, 2014, 2:39 PM UTC

tankenmate wrote: post #190

cbsmith wrote: post #84

Earlier quoted context omitted.

> double forks That's actually not something you want. It turns out that makes process management unnecessarily hard. That said, the glibc implementation isn't terribly good either. The CW is not to use either. > I think part of systemd's problem, as much as Poettering et al will try to deny it, is that it is full of NIH. The most exasperated criticism I see about systemd is its use of dbus for a communications infra…

You need to double fork() in order to ensure that the daemon won't be the controlling owner of the tty once it calls setsid(); i.e. that it will be re-parented to init. So personally as a sysadmin that occasionally runs daemons from the command line I much prefer a double fork(); I don't want the daemon to exit when I log out.

Both forking and double-forking are completely wrong behavior for supervised daemons run as part of any automated system. Forking makes sense for small systems which lack any automated supervision and where a human admin is responsible for all process starting and stopping, but it's a bug anywhere else. Modern Linux has various methods for working around this bug (like the method of assigning an alternate process for orphaned descendants to be reparented to, which systemd uses, AFAIK), but really any production-quality daemon should provide a non-forking way to start it.