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.
Systemd Sucks, Long Live Systemd
121–130 of 272 posts
Re: Systemd Sucks, Long Live Systemd
#122I'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…
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
#123At 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…
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
#124Earlier 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…
Re: Systemd Sucks, Long Live Systemd
#125Earlier 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.
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
#126Why 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.
Re: Systemd Sucks, Long Live Systemd
#127Most 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…
Re: Systemd Sucks, Long Live Systemd
#128Earlier 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…
I totally agree with your second paragraph, that is why I'm working on fixing shell :)
This entry in particular is relevant to your concerns:
Re: Systemd Sucks, Long Live Systemd
#129Earlier 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.