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

Systemd Sucks, Long Live Systemd

naftuli.wtf

Post reply on HN
Print view View original

101–110 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#101

Post by CaptSpify »

microcolonel wrote: post #86
CaptSpify wrote: post #29

I'll put my opinion in the middle ground with systemd as well. I like a lot about it, and I dislike a lot about it. I really think the best thing they could have done would have been to make it modular. If people could just turn off the "features" that they don't want, there wouldn't be so much bitching about it. Instead they keep trying to shove everything into one giant pile, and don't understand why people get ups…

The repository and build system are set up to allow you to disable almost everything (except core services like evdev, the "systemd" init process, journald, and D-Bus). Distributions have just found it so pointless to strip it down that they've left it largely as one package. You're entirely welcome to use your distribution's packaging scripts to produce a reduced package, if one doesn't exist yet. As far as I'm conc…

> core services like evdev, the "systemd" init process, journald, and D-Bus

Oh, so just most of the things that people hate about it. No biggie then. /sarcasm

> People get upset because they're too lazy to run the build system themselves. People who are unwilling to run the build system and read the mailinglist are unfit to ship anything short of the whole thing anyway. In my opinion, if these people are complaining, it is meaningless. They are not the sort of people who can figure out how to fit their system into 8MB of flash on a tiny SoC, so them complaining that the systemd package is more than 10 megs is like a child complaining that their bedsheets are too barbie and not buzz lightyear enough.

I can't say I've ever seen anyone complain about that. I have seen, however, people complain about broken logs, unreliable processes, butchered output, hacky fixes, obscure errors, etc.

And this is the attitude that I have an issue with. Systemd has a lot of good sides, but it also has a lot of warts. Pretending that people's legitimate concerns are nonsense is a waste of everyones time, and are what makes people who have issues want to complain at every turn.

Re: Systemd Sucks, Long Live Systemd

#102

Post by semi-extrinsic »

otabdeveloper wrote: post #94
FeepingCreature wrote: post #14

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

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.

> 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 are better than even I have to spend two hours debugging why by enabling internal logging in that service, running in debug mode etc.

Like when I tried to switch to networkd, and had the wrong password for a wifi I was connecting to, networkd never told me this in any way I could find. Had to go back to the old solution (after an hour of pulling my hair out) before I realised the password was wrong.

Re: Systemd Sucks, Long Live Systemd

#103

Post by prewett »

rodgerd wrote: post #89
lisivka wrote: post #45

Earlier quoted context omitted.

Yep, they are. Shell is lingua franca for system administrators for whole history of UNIX.

Which one? ash? csh? tcsh? ksh? I don't think you have as much experience with Unix as you would like us to think you do.

What do you mean which one? It's /bin/sh. /bin/sh has always been the shell used, because it's the only one guaranteed to be on all unixen. No system ships their init scripts written in ash, csh, tcsh, ksh, or anything besides /bin/sh (except Linux, which may have used /bin/bash, since /bin/sh was symlinked to /bin/bash)

You might have made your personal init scripts in some other shell (until you learned about design failures of csh), but I'm willing to bet your Unix distributor did not.

Re: Systemd Sucks, Long Live Systemd

#104

Post by viraptor »

hedora wrote: post #15
jcrites wrote: post #8

Earlier quoted context omitted.

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

> Pid 1 runs its own DNS server now.

It doesn't. Systemd has its own resolver (systemd-resolved), which has other issues, but it does not run in PID 1. It's a completely separate process.

// I'm enjoying watching the points bouncing up and down, but if you disagree in some way, please comment :)

Re: Systemd Sucks, Long Live Systemd

#105

Post by MertsA »

CaptSpify wrote: post #29

I'll put my opinion in the middle ground with systemd as well. I like a lot about it, and I dislike a lot about it. I really think the best thing they could have done would have been to make it modular. If people could just turn off the "features" that they don't want, there wouldn't be so much bitching about it. Instead they keep trying to shove everything into one giant pile, and don't understand why people get ups…

>the best thing they could have done would have been to make it modular.

They did, systemd is very modular in nature. The only things that aren't modular that spring to mind is the journal and systemd the init requires dbus (sort of).

systemd the project has a little bit of everything that you need in an operating system but systemd the init is stripped down to being able to parse unit files, supervise services, and generate and walk the dependency graph from where you currently are to where you're aiming to be.

All of the random features that you always hear about are all individual self contained services. So for example, systemd the init knows nothing about the format of /etc/fstab or SysVInit scripts. It only understands how to work with unit files, the way this works is that there's separate self contained generators that parse /etc/fstab and all of the old init scripts and creates unit files that only exist in a tmpfs directory.

If you don't want something like systemd-networkd then you don't have to have it. You can just compile systemd without it, turn it off at runtime, or just configure systemd to not start said service. You can take systemd and make it suitable for everything from embedded use, to servers, to a multiseat desktop.

Re: Systemd Sucks, Long Live Systemd

#106

Post by sebcat »

> The justification for storing logs in a binary format was speed and performance, they are more easily indexed and faster to search.

Are there any benchmarks for this? I don't know why, and I may be doing things wrong, but journalctl -lu --since yesterday in our prod env takes a couple of seconds before I see any output, while a (z)grep on a date rotated, potentially compressed log file on a non-journald system is generally instantaneous.

On a side note, I really like machine parsable, human readable logs, and I've never had any speed or performance issues with it when dealing with volumes of hundreds of millions of log entries, though that may be because I don't know any better.

Re: Systemd Sucks, Long Live Systemd

#107

Post by MertsA »

digi_owl wrote: post #97
microcolonel wrote: post #84

Earlier quoted context omitted.

For what it's worth, I don't think Lennart is against non-Linux systems; he just doesn't care. And as an avid OpenBSD user, as well as an avid Linux user, I can't blame him. Linux has great APIs like cgroups, inotify (in my opinion considerably more useful than the equivalent use of kqueue), and others. OpenBSD is the other unixy system which I think offers something valuable and unique, and it has its own APIs to of…

He has in the past advocating ignoring everything unix about Linux when developing for it.

No, he advocated for making design decisions based on what's best for Linux, not a compromise for other operating systems.

Re: Systemd Sucks, Long Live Systemd

#108

Post by flukus »

sebcat wrote: post #106

> The justification for storing logs in a binary format was speed and performance, they are more easily indexed and faster to search. Are there any benchmarks for this? I don't know why, and I may be doing things wrong, but journalctl -lu --since yesterday in our prod env takes a couple of seconds before I see any output, while a (z)grep on a date rotated, potentially compressed log file on a non-journald system is g…

My question would be "is searching worth optimizing for anyway?". Log files are typically only read when things go wrong or by automated systems where a few seconds here or there doesn't make much of a difference.

Faster to search often means slower to write too, I'd prefer faster to write and slower to search if I had to choose.

Re: Systemd Sucks, Long Live Systemd

#109

Post by bazurbat »

chubot wrote: post #59
agumonkey wrote: post #20

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

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 string or something with patterns which expands in unexpected place, etc. Properly handling those cases will make your script ugly mess. Actually I find the mental burden when writing shell scripts is very akin to programming in C.

Re: Systemd Sucks, Long Live Systemd

#110

Post by zvrba »

quickben wrote: post #25
xenadu02 wrote: post #13

Earlier quoted context omitted.

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…

"The C compilation model of separate header files is not a good design" This is probably just your lack of experience not having worked on 50+ million LOC compiling for 12 hours and not having anything else as a better option. There is a reason these things exist.

I've worked on a project that combined C++ and C# in approximately equal amounts (say 2MLOC each). The C++ project compiled and linked for 20 minutes , C# compiled and linked in under 2 minutes. Go figure.

I agree: C and C++ compilation model is not a good design. It's a patch for not having a decent module system. Heck, even Borland Pascal compiled faster in 90-ies than C++ does now on an orders of magnitude faster machine.

Post reply on HN