Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why systemd?

blog.jorgenschaefer.de

Post reply on HN
Print view View original

81–90 of 263 posts

Re: Why systemd?

#81

Post by simoncion »

mmagin wrote: post #40
ultramancool wrote: post #32

Earlier quoted context omitted.

Classic sysvinit or BSD-style init doesn't rely upon this sort of functionality at all. Just some simple scripts. No need to complicate it any further. A few signals are all that are needed.

Simple scripts? Have you looked at the shit in /etc/init.d in a modern linux distribution? $ wc -l * | sort -n | tail 274 exim4 286 apache2 290 dnsmasq 298 nfs-common 350 clamav-freshclam 364 udev 386 checkroot.sh 420 clamav-daemon 465 clamav-milter 9893 total If you look into these, you'll find tons of near-duplicate code between scripts, and frequently every script reinvents the wheel in one way or another.

/etc/init.d $ for I in * ; do printf "%s %s \n" $(cat $I | grep -v -e '#' | wc -l) $I; done | sort -n | grep -v net.e | tail

  142 mysql
  142 sysfs
  157 kexec
  172 udev
  172 xdm
  182 apache2
  195 bootmisc
  232 named
  297 dmcrypt
  736 net.lo
This is on an OpenRC Gentoo system. There's very little duplicated code in the init scripts.

You might well complain that many these init scripts are substantially longer than the equivalent systemd unit files. Your complaint would be valid. Thing is, many of these init scripts do so much more than the equivalent systemd unit files. Ferinstance, the postgres and mysql unit files that I've seen permit no user configuration (like, such as, altering daemon listen port, config file location, and the like). [0] They also don't do any sort of housekeeping such as verification of the validity of the service's configuration file, checking and repairing mode and ownership of the same, and verifying the existence of the service's data directory.

I understand that OpenRC wasn't being considered for Debian Jessie, but it does a lot of things right, and is (IMO) head-and-shoulders above SysV init. (But then, isn't even bringing up SysV init kind of beating on a dead horse? We all agree that it really needs improvement.)

If you're interested, Gentoo's apache2 init script is here: http://pastebin.ca/2845519 . For reference, the apache2 systemd service file is here: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/www-... .

For a look at a simpler init script, check out the script for dnsmasq: http://pastebin.ca/2845520 . Looks pretty simple, no? At least as simple as the systemd service files we've been seeing, yes? The config file for dnsmasq is a single line: DNSMASQ_OPTS="--user=dnsmasq --group=dnsmasq" .

OpenRC provides complexity when you need it, and gets out of your way when you don't.

[0] I don't have systemd installed, so I might be missing the user configuration facilities. If they exist, and the configuration files have any appreciable complexity, then their line count must be counted against the unit file's line length.

Re: Why systemd?

#82

Post by nn3 »

drdaeman wrote: post #19
ultramancool wrote: post #5

Am I the only one who's disgusted with this bloated, convoluted, dbus-dependent pile of crap? I mean, c'mon, binary log files? I'll pass, thanks. It replaces way more than it needed to. I prefer the BSD-style philosophy, nice, simple rc.conf, used to run Arch till it got infected with this garbage too. It slowly progressed away from it's BSD-style roots. So recently, I just gave up and moved to FreeBSD. Not a single…

I think I'm mostly fine with journald (as a concept). At least I can explain reasoning for it to myself. A switch from non-structured to structured data provides a significant advantage, and indexes are useful. At least I had too many times grepping a multi-gigabyte log file. Sure, relatively modern (RFC5424) syslog protocol has structured data too, but in my experience most software had never bothered to use it. So,…

sqlite (or other "real databases") need a fsync for every or at least many transaction to be data safe. Without that it is far more prone to losing data than journald, because with a write ahead log the window for losing data is far bigger.

And a journal that has another journal inside it would be somewhat silly. A simple write log can be done better.

I don't think fsync on every log commit is a good idea. This would be more a DOS attack.

That said I'm somewhat troubled by the cavalier attitude to log data safety in journald too.

Re: Why systemd?

#83

Post by cbsmith »

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.

Re: Why systemd?

#84

Post by cbsmith »

Sanddancer wrote: post #17

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. One of the things this post criticizes, and Poettering criticizes, is the BSD-inherited daemon() function. Being curious, I looked at the function's implementation, both in FreeBSD's implementation, and glibc's implementation. FreeBSD's implementation handles pretty much everything the daemon writer themself…

> 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 infrastructure, because dbus is both a system bus and a desktop session bus, and everyone associates it with the latter. If they'd just done the NIH thing and rolled their own communications protocol (like various other parties), they'd be deflecting a lot of that criticism.

Honestly, the NIH syndrome seems at least as prevalent amongst systemd's critiques.

Re: Why systemd?

#85

Post by dalias »

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.

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.

Re: Why systemd?

#86

Post by cbsmith »

gtaylor wrote: post #44
na85 wrote: post #10

Earlier quoted context omitted.

It already has taken over despite being mediocre at best. Mostly I feel that it got an undue jumpstart thanks to RedHat trying too hard to be bleeding edge, and Upstart/OpenRC not having as high-profile a backer.

To be fair, Upstart was pretty awful in the early goings. It seems to be a lot more reliable and predictable now, but that's a fairly recent development for us (when we upgraded to Ubuntu 14.04 LTS).

The golden rule of technology hype: once people start abandoning a technology is when it starts being functional.

Re: Why systemd?

#87

Post by cbsmith »

nisa wrote: post #18
audidude wrote: post #8

Earlier quoted context omitted.

> In order to fix a system, a person needs to understand it as well as be able to make a change in it. So if I follow you, it would be easier to grok the whole system if all the code was in different places?

Opaque C code that sits in lots of spread binaries and some end-user documentation in man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other complex systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r ` is often the first step on the way to understand and learn som…

Actually, the nice thing about systemd being built around dbus is you can track most of what is going on with it simply by tracking the flow of messages in dbus.

If you find C-code "opaque", you're already kind of screwed in the Unix world...

Re: Why systemd?

#88

Post by dmix »

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…

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.

Re: Why systemd?

#89

Post by cbsmith »

nisa wrote: post #31
audidude wrote: post #27

Earlier quoted context omitted.

> Opaque C code that sits in 20 binaries and some man pages don't help you a lot if have to debug an issue. It's okay from a user perspective but with systemd (or other systems that rely on in this principle) you need to start reading c-code, start gdb, deal with dbus... if it's a toolbox of scripts a `grep -r ` is often the first step on the way to understand and learn something and fix the problem. What's opaque ab…

> What's opaque about Free and Open Source C code? Everything if you are sysadmin/developer trying to fix an issue. At first you need debugging symbols to pinpoint the problem, then you need to read the source.. it all takes time. E.g. you need to learn about dbus-monitor and dbus calls and need to grasp some internal concepts of systemd if something goes wrong. It takes time and patience you usally don't have or don…

> At first you need debugging symbols to pinpoint the problem

These days there is really no reason you can't have the debug symbols already around. But you've got a fine point there, the Bourne shell debugger is much more convenient and easy to come by, and it makes postmortem analysis with core files trivial... ;-)

> then you need to read the source..

As much as you need to do that with any system, you need to do that with them all.

> E.g. you need to learn about dbus-monitor and dbus calls

Yes... and if not you have to learn about whatever other mechanism is being used to provide encapsulation and separation of concerns between the components of the system...

> It takes time and patience you usally don't have or don't want to spend on such details.

This really boils down to, "I'm already really familiar with this other system...". It's a legit argument for why you might not use systemd. It's not a terribly legit argument for why systemd is bad.

The rc system doesn't address a fraction of the problem and actually makes a number of things worse. Heck, the rc man page you linked to links to four or more other components of the system, including the voluminous "simple because it is shell" rc.conf.

Re: Why systemd?

#90

Post by jmspring »

mikepurvis wrote: post #69
jmspring wrote: post #9

Earlier quoted context omitted.

It is interesting looking at how differing linux distributions approach this problem as well as things like connection management. Many do seem to be moving towards things like systemd. Angstrom Linux for the BeagleBone even bundled something called connman for managing network connections. Attempting to navigate the path of systemd plus connman to get networking to work the way I wanted was a pain. Some of the more…

Connman has a lot of promise, and I like the theory and design of it, but found it very frustrating and incomplete in practice. Basic functionality like "connect to my wireless on startup, and keep on trying to connect if you don't succeed right away" is missing. Also, it's being rapidly iterated and there isn't a PPA for Ubuntu, which sucks.

Potential, yes, but with devices like beagleboard where you are often also using a WiFi adapter that is not super strong, the frustrations grow.

Fewer moving parts means easier debugging.

Post reply on HN