Live data from Hacker News

Systemd Sucks, Long Live Systemd

naftuli.wtf

121–130 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#121

Earlier quoted context omitted.

Systemd isn't an init system, it's a service (a.k.a daemon) management daemon. Its primary purpose is to restart and diagnose failing daemons cleanly. Systemd won for one simple reason: it's the only tool that accomplishes this task without bugs. We've been running daemontools for almost a decade in production, and it's a nightmare of bugs. Very glad to be finally switching to systemd.

Systemd is definitely an init system.

As well as logging daemon, dbus daemon, session manager, device node manager and many other things.

Re: Systemd Sucks, Long Live Systemd

#122

I'd probably respect SystemD a lot more if it measured itself against a modern init system like Gentoo's OpenRC instead of pretending it's invented dependency handling. https://wiki.gentoo.org/wiki/Comparison_of_init_systems > OpenRC provides a number of features touted as innovative by recent init systems like systemd ...

OpenRC is still more difficult to write init scripts for than systemd; and offers less flexibility in scheduling inits. For example, I can add a 'before' clause to a custom systemd service unit, and I don't need to modify the subsequent units to depend on my custom unit. This is especially useful when you want a custom forking or oneshot service to reliably run before a standard service shipped with a package in your…

Less flexibility how? Please be specific. Before clause exists in OpenRC and is typically rarely useful.

The things it has are incomplete and too integrated, making them hard to replace with working alternatives that do what you want.

Re: Systemd Sucks, Long Live Systemd

#123
post #117

At the risk of sounding heretical, I kind of find myself in the middle ground regarding systemd - I was initially highly skeptical of it, and I still think it's problematic that it is so Linux-centric and will cause problems maintaining software to run both on Linux/systemd and on *BSD. The way it was pushed on distros was problematic, in my opinion. But having used a couple of Linux systems running systemd - Raspian…

Some parts may be useful, some parts are downright awful, but the clincher is that it is all a big wadded up ball of code.

Damn it, the LFS team basically adopted eudev, of Gentoo fame, because extracting udev from systemd required manual intervention over and over.

Re: Systemd Sucks, Long Live Systemd

#124
post #4

Earlier quoted context omitted.

I hated systemd when I had to start using it. It tries to do way too much. The antithesis of the the Unix philosophy. Journalctl grew on me though.

Who said the unit philosophy was the be-all, end-all? Unix doesn't even believe it's own philosophy because it's too damn painful. Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? Unix is just a collection of random decisions made by various people over the years. The Unix philosophy is really more like "I've always done it that way so don't you dare change i…

Yes, yes, yes! Never has someone articulated what I believe so damn well. There is so much blind worship of tradition and heroes in the UNIX world, so glad to see someone else believes what I've always believed.

Re: Systemd Sucks, Long Live Systemd

#125

Earlier quoted context omitted.

Systemd is definitely an init system.

As well as logging daemon, dbus daemon, session manager, device node manager and many other things.

That session manager, logind, is a particular mess.

Here you have a daemon that ties into PAM that tries to second guess the kernel regarding what constitutes a session.

Effectively systemd is becoming something akin to Android. It may be using the Linux kernel, but it is not the GNU/Linux we have grown familiar with over the years.

Re: Systemd Sucks, Long Live Systemd

#126

Why would you run the Exec command through systemd-escape? The help text says that's for the NAME of the unit... Am I missing something? Also, I'm failing to think of a scripting purpose that requires you to place non-trivial bash directly in a systemd unit that couldn't be solved by writing out the script somewhere and just invoking the script in the unit.

> Now agreed, if your workflow demands that you embed a Bash while loop in a unit, you’re already in a bad place, but there are times where this is required for templating purposes. It's right there in the post. I have indeed had to do something like this in the wild to run a Docker container with special needs.

I don't see how "templating purposes" answers the question. I deploy services on VMs that need to parameterized and I can parameterize via templating a written-to-disk shell script that is then just simply executed in the unit... or I can have more dynamic parameterization and use environment variables and Environment= lines in the unit. The latter solution means the substitution is effectively happening in the same place as if they were inlined parameters, so I can't imagine a scenario when it wouldn't be workable.

Re: Systemd Sucks, Long Live Systemd

#127

Most people I hear having problems with Systems is either on Redhat or Debian - not realising the both are mangling systemd badly. RHEL took in systemd way too early and are missing a lot of needed functionality. Also the have an ungodly amount of patches on top - so much you could argue it should be named redhatd instead. Debian just chooses to take the worst possible middle position due to politics. All of the disa…

I am running systemd on Gentoo. (like Sabayon) While some of the features are nice, it is a royal pain to upgrade due to intertwined deps and forced restarts. And it doesn't do anything OpenRC couldn't do, in fact its journald is a pain which had to be worked around. OpenRC way of doing socket activations and dbus activations also works slightly better (in case something crashes) It does parallelism just as well, ser…

Yeah, Gentoo is quite nice in that regard, but isn't it still focussed on openrc? I was a ten plus years gentooo user before I switched to Arch (mostly because I got fed up with compiling)

Re: Systemd Sucks, Long Live Systemd

#128
post #59

Earlier quoted context omitted.

Shell and bash are actually excellent at this, but people don't like writing shell scripts. This is just process chaining. Take a look at DJB's or the more modern runit for init toolkits that compose. https://cr.yp.to/daemontools.html http://smarden.org/runit/ Here is a bash function that retries N times: retry() { local n=$1 shift for i in $(seq $n); do "$@" done } retry 5 echo hi Then you can compose with a timeout…

Isn't it just repeats the command 5 times instead of retrying? IMO Bash with it's multitude of annoying quoting and field splitting rules, many irrelevant features focusing on interactive use, and error handling as an afterthought is just wrong choice for writing robust systems. It's too easy to make mistakes. And it still works only in the simplest cases, until somebody evil deliberately pass you newline delimited s…

If the command is a daemon, that's basically retrying. But if you want to check the exit code, that's easy to do inside retry().

I totally agree with your second paragraph, that is why I'm working on fixing shell :)

http://www.oilshell.org/blog/

This entry in particular is relevant to your concerns:

http://www.oilshell.org/blog/2016/11/06.html

Re: Systemd Sucks, Long Live Systemd

#129
post #113

Earlier quoted context omitted.

> Its primary purpose is to restart and diagnose failing daemons cleanly. If this is true, and speaking as a systemd user for close to five years now, it universally sucks at its primary purpose. Specifically, whenever a service fails, I've lost count of the number of times systemd has barked out useless errors with 200 lines that boil down to "service has entered failed state". Whenever a systemd service fails, odds…

Networkd does not handle WLAN authentication. This is the job of wpa_supplicant, which is the defacto standard on linux in every setup until maybe iwd from Intel takes over.

Yeah, but I'm sure you agree networkd should propagate errors from wpa_supplicant such that they reach the user, instead of piping them to /dev/null (not literally, but you get my point)?

Re: Systemd Sucks, Long Live Systemd

#130
I get the feeling anyone who complains about systemd is just a hobbyist jumping on a hate bandwagon. For anyone who manages production systems, systemd is a godsend compared to the homegrown-per-distro shell based init systems.
Post reply on HN