[deleted]
Systemd Sucks, Long Live Systemd
11–20 of 272 posts
Re: Systemd Sucks, Long Live Systemd
#12Earlier quoted context omitted.
As are most Bash init files with InitV... At some point we should consider that the init system as a whole (including the configuration scripts for each daemon) _is_ complicated and often confusing. In this regard, writing something like SystemD to elegantly handle most of the usecases is actually a good idea.
Bash init files may not be particularly feature rich, but they are hardly "complicated". 90% of every file is boilerplate built around: stop, start, status (after all restart is just stop+start). Proponents of SystemD can make some good points, but trying to claim init.d is complicated comes across as desperate.
You forget that sysvinit also required fun extras like supervisord to run simple executables because it relied on applications demonizing themselves.
Writing systemd unit files for my applications is a breeze compared to the shit I had to do for sysvinit - especially when I factor in apps I DIDN'T write that I need unit files for (teamcity, etc) and there's less surprise with SELinux policy transitions (and unlike most setenforce 0 is not the first thing I run on a server, I work in healthcare and a solid MAC layer is important to me).
Re: Systemd Sucks, Long Live Systemd
#13I don't care for SystemD for the same reasons that I don't like MacOS's init system: it an opaque, confusing mess.
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 it".
fork/exec is garbage. Signals are garbage. You basically can't make any API calls after fork or in a signal handler because threads came after. The interaction of fork and threads is bananas and many hacks have been required over he years to paper over the problems.
The layout of /usr/bin, /usr/sbin, /usr/local/bin, et al isn't a good design. It's dogshit but it was necessary because early Unix file systems couldn't span multiple volumes and early disk systems were small.
The C compilation model of separate header files is not a good design. People have retroactively determined some of the side-effects are not only good but The One True Way. In reality the design was a result of extremely limited RAM and slow CPUs. The preprocessor itself was never designed, just grafted on ad-hoc.
Unix file permissions are shit. Every unique combination of permissions requires a group. Owners are by simple integers. NFS legitimately gives people nightmares.
Let's not even get into everything is a file, except when it's not, and some files are more equal than others.
What about dependency hell? How's that "simple" model working out?
The "Unix philosophy" can piss right off.
Re: Systemd Sucks, Long Live Systemd
#14I'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 ...
Re: Systemd Sucks, Long Live Systemd
#15Earlier 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.
I think systemd needs to do most of the things it does. Russ Allbery's analysis of systemd [1], written as part of Debian's evaluation of whether to switch to systemd, explains the benefits. Journal integration is something that Russ was also skeptical about, until he realized its value: * Integrated daemon status. This one caught me by surprise, since the systemd journal was functionality that I expected to dislike.…
Pid 1 runs its own DNS server now. It also launders kernel calls for non-setuid xorg (breaking rootless x on non-systemd boxes, since the kernel can't be bothered to consistently check process uid or gids, apparently). In turn, that means it must have some baroque authentication subsystem too. There is no way you need that in init. The amount of ancillary damage systemd causes far outweighs any possible benefits there are to improving init.
Also, I have never seen a systemd box emit log lines like that for a failed service. It invariably points at some useless logfile with obscure systemd messages in it instead of the stderr of the failed process. This is on clean ubuntu and debian installs. Maybe it is user error, but I doubt it. (Though there is no command line in the examples...)
Anyway, I'm happy to cleanse with fire instead of RTFM at this point. On a related note, I just learned the solaris init system and started using openbsd's again.
I prefer them both to systemd. They are at opposite ends of a spectrum. The openbsd approach is well curated shell scripts. I think systemd was heavily inspired by the solaris thing.
Re: Systemd Sucks, Long Live Systemd
#16Earlier quoted context omitted.
As are most Bash init files with InitV... At some point we should consider that the init system as a whole (including the configuration scripts for each daemon) _is_ complicated and often confusing. In this regard, writing something like SystemD to elegantly handle most of the usecases is actually a good idea.
Bash init files may not be particularly feature rich, but they are hardly "complicated". 90% of every file is boilerplate built around: stop, start, status (after all restart is just stop+start). Proponents of SystemD can make some good points, but trying to claim init.d is complicated comes across as desperate.
> Bash init files may not be particularly feature rich, but they are hardly "complicated".
Are you trying to make the argument that shell scripts are simple, easy to read, and maintainable?
Permit me to disagree.
Re: Systemd Sucks, Long Live Systemd
#17Why 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.
Re: Systemd Sucks, Long Live Systemd
#18Earlier 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…
Most of this comment is incorrect.
Re: Systemd Sucks, Long Live Systemd
#19Earlier 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.
I think systemd needs to do most of the things it does. Russ Allbery's analysis of systemd [1], written as part of Debian's evaluation of whether to switch to systemd, explains the benefits. Journal integration is something that Russ was also skeptical about, until he realized its value: * Integrated daemon status. This one caught me by surprise, since the systemd journal was functionality that I expected to dislike.…
I thought that was the part of systemd that was universally liked? The best arguments against systemd seem to be that everything becomes implemented in or tightly bound to it.
Re: Systemd Sucks, Long Live Systemd
#20Systemd ideas I'm all for but it only hints at linux lack of clean abstraction power. sysvinit was full of redundancy; apparently BSD found a way to make a thin abstraction layer to make init files clean.
Bash isn't "good" at hinting proper abstractions, I rarely see talks about this, maybe gurus can see through the rain.
I keep seeing a place for a tiny lambda friendly intermediate layer .. Just so you can compose properties of your services like clojure ring middleware.
(->
(path "/usr/bin/some-service" "arg0" ...)
(wrap :pre (lambda () ...)
:post (lambda () ..))
(retry 5)
...
(timeout 5))
ps: the idea is that (retry 5) is a normal language function, and not a systemd opaque built-in, you can write your own thing, and the most used can go upstream. Hoping to avoid the sysvinit fragility and redundancy.