Why systemd? • Hacker News Board

Re: Why systemd?

#41

Post by smutticus » Tue, Sep 23, 2014, 1:16 AM UTC

nisa wrote: post #12

audidude wrote: post #7

Earlier quoted context omitted.

> udev is a core component in any modern linux system I see systemd absorbing it as nothing but a political move and a power grab. I think this is a bit of a stretch. It's not like they did a hostile take over of udev. The maintainers also thought systemd was the right place for that code to live. As for bloat, there certainly have been some new features, but so much of the systemd code (from what I can tell) was exi…

> It's not like they did a hostile take over of udev. http://lists.freedesktop.org/archives/systemd-devel/2014-May... (via http://redd.it/2a2tz5 ): > Also note that at that point we intend to move udev onto kdbus as transport, and get rid of the userspace-to-userspace netlink-based tranport udev used so far. Unless the systemd-haters prepare another kdbus userspace until then this will effectively also mean that we w…

It's this kind of crap that scares me away from systemd. I have no problems working with current init structures, so I gain nothing from systemd. It basically just removes options from me, and gives me nothing in return that I actually want.

What we ultimately lose with systemd is modularity. If we cannot upgrade systemd without also upgrading the kernel, then systemd might as well be considered part of the kernel.

Re: Why systemd?

#42

Post by navait » Tue, Sep 23, 2014, 1:16 AM UTC

mhogomchungu wrote: post #6

Lots of people do not seem to understand the criticism of systemd. systemd = init system + a whole lot of other things. When people complain about systemd,they usually do not complain about what it does or how it does it in the init system part.That part is pretty solid as far as functionality is concerned. When people complain about systemd,they usually complain about the "whole lot of other things" part.Lots of peo…

This init process debate has brought out one of the worst elements of people in the FOSS community: treating some FOSS technology as an extension of their identity.

Let's keep some perspective here. We are literally just talking about an init system. There are many others you can use. systemd is not taking away your freedom in any meaningful sense of the word "freedom". Debates should be about the technical merits of system not baseless accusations that they are making a power grab.

Re: Why systemd?

#43

Post by nisa » Tue, Sep 23, 2014, 1:16 AM UTC

audidude wrote: post #35

nisa wrote: post #31

Earlier quoted context omitted.

> 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…

> I don't want to say that one is better than the other but the latter is for most folks far easier to debug and modify than the first. Generally bad form to make claims on behalf of "most folks" since you are in fact a single person. It's totally a valid argument if you say this on your own behalf. And yes, bugs happen. But fixing the C code, is in my experience, much easier than tracking them down in `bash -x`. Esp…

Yes. Shell scripts are it's own unique kind of hell. I'm really speaking on my behalf here. I can read shell good enough to follow and debug issues in it. However digging into internals of systemd and its interactions with dbus and other binaries is opaque for me.

Maybe it's just a different perspective - as a developer systemd likely eases a lot of pains and makes otherwise problematic and error-prone problems easy but as an sysadmin that mostly deals with servers it feels sometimes like forced unnecessary complexity that can introduce difficult to debug issues.

Re: Why systemd?

#44

Post by gtaylor » Tue, Sep 23, 2014, 1:17 AM UTC

na85 wrote: post #10

dsr_ wrote: post #4

The reason people use UNIX-like systems is because they work reliably. In order to make a complex system work reliably, it needs to be easily fixed. In order to fix a system, a person needs to understand it as well as be able to make a change in it. And in order to understand a system, it helps very much if that system is straightforward and lucidly verbose. I hope systemd will live or die on its merits; I fear that…

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).

Re: Why systemd?

#45

Post by smutticus » Tue, Sep 23, 2014, 1:18 AM UTC

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…

I completely agree with you.

Re: Why systemd?

#46

Post by m45t3r » Tue, Sep 23, 2014, 1:18 AM UTC

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…

Well, the problem is, you only changed the problem. Now instead of depending of a specific init system, you're depending of a specific implementation of daemon() function (which I imagine is not really standard, since if it was glibc would implement it correctly). Maybe you could create daemon_correctly() function that was guarantee to implement daemon as it should, but you would incur the risk of having the case of strlcpy() again (glibc didn't added this function since the maintainer said it was messy and bloated, so almost no software used it).

And anyway, correctly daemonizing is only part of what systemd got right. I think the fact that you don't need to track services with random programs anymore (since systemd knows each and every process parent thanks to cgroups) is something much more interesting than just getting daemon() right.

Re: Why systemd?

#47

Post by mmagin » Tue, Sep 23, 2014, 1:18 AM UTC

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.

And on my Debian testing system with systemd, the longest service definition is 46 lines! (/lib/systemd/system/getty@.service)

Re: Why systemd?

#48

Post by gtaylor » Tue, Sep 23, 2014, 1:19 AM UTC

nisa wrote: post #43

audidude wrote: post #35

Earlier quoted context omitted.

> I don't want to say that one is better than the other but the latter is for most folks far easier to debug and modify than the first. Generally bad form to make claims on behalf of "most folks" since you are in fact a single person. It's totally a valid argument if you say this on your own behalf. And yes, bugs happen. But fixing the C code, is in my experience, much easier than tracking them down in `bash -x`. Esp…

Yes. Shell scripts are it's own unique kind of hell. I'm really speaking on my behalf here. I can read shell good enough to follow and debug issues in it. However digging into internals of systemd and its interactions with dbus and other binaries is opaque for me. Maybe it's just a different perspective - as a developer systemd likely eases a lot of pains and makes otherwise problematic and error-prone problems easy…

As a sysadmin, I'll take systemd units over SysV init scripts any day. They tend to be shorter, more simple to read, and I don't have to worry about the race conditions or services not restarting correctly due to varying daemonization techniques.

Re: Why systemd?

#49

Post by jsnell » Tue, Sep 23, 2014, 1:21 AM UTC

audidude wrote: post #27

nisa wrote: post #18

Earlier quoted context omitted.

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…

> 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…

My machine with systemd (FC20) doesn't boot up at all unless systemd loglevel is set to debug on the command line. Even with it it takes about 5 minutes to boot. Luckily I don't need to reboot often, but every single time there's a small fear that some upgrade has made systemd crap up even worse, and the system won't boot at all.

How do you debug a complete black box, where turning on debugging partly fixes the problem. You really don't. This is literally the worst debugging experience I've had in 20 years of using and maintaining Linux systems -- and that includes trying to do these things with much less knowledge and only limited internet access back in the early days.

I love the ideas behind systemd. It's too bad, even if not surprising, that the implementation is a flaming pile of garbage.

Re: Why systemd?

#50

Post by codemac » Tue, Sep 23, 2014, 1:29 AM UTC

AceJohnny2 wrote: post #14

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…

> dbus-dependent pile of crap? This seems to come up frequently. I'm curious: how alternatively would a local process communicate with the Init daemon?

I'm curious:

Why is the init daemon what a local process should communicate with?

A daemon that managaes other daemons doesn't need to be PID 1, even to reap zombies.

Secondly, daemons shouldn't care what process is managing them, a principled approach to communication between the daemon manager and a daemon would probably include handing off sockets/ports/fds, but probably not much else.