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

151–160 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#151

Post by digi_owl »

AnonymousPlanet wrote: post #144
digi_owl wrote: post #95

More and more systemd is becoming symptomatic of deeper divide within the Linux "community". The split being between those that embraced Linux for being a free, in both senses, _nix unburdened by AT&T and running on commodity hardware, and those that got to know it after the dot-com crash as the L in LAMP. The former cares for Linux as a _nix, the latter could not care less about _nix and may see it as a vestigial ap…

I'm not so sure if it really has that much to do with heritage. A lot of us like the design principles you can see in Unix and that are pretty much absent in systems like Windows NT. They very much reflect the conclusions I came to after over fifteen years of building and debugging systems. But, yes, I have the impression that a lot of Linux users would just as gladly use a modern BeOS or a ReactOS, regardless of the…

There is change and there is change.

Re: Systemd Sucks, Long Live Systemd

#152

Post by microtonal »

krylon wrote: 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…

I am also in the middle ground, but I have moved from the opposite direction. I used to like systemd a lot, especially for its simple unit files (compared to ugly System V shell scripts) and the fact that it could properly track processes and restart them on failure.

I have become a bit more skeptical, because most of the problems that I recently had seemed to be related to systemd. Including some networking problems, long boot delays because systemd decides to wait 90 seconds be default on some conditions that it considers to be errors, and problems such as having to restart systemd-logind manually because of some d-bus update [1]. Before the update, logging in via SSH blocked for a large amount of time.

The most annoying part is that some of the problems take quite a bit of work to debug due to the opaque nature of modern systemd/d-bus/...-based systems.

[1] https://major.io/2015/07/27/very-slow-ssh-logins-on-fedora-2...

Re: Systemd Sucks, Long Live Systemd

#153

Post by lksgkjhsgkjh »

semi-extrinsic wrote: post #129
Mic92 wrote: post #113

Earlier quoted context omitted.

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

networkd doesn't know about wpa_supplicant, just as it doesn't know about openvpn, vpnc, ...

If you want a network manager that does know about those and might give more helpful error messages if they fail, use for example NetworkManager.

Re: Systemd Sucks, Long Live Systemd

#154

Post by lksgkjhsgkjh »

digi_owl wrote: post #125
AstralStorm wrote: post #121

Earlier quoted context omitted.

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.

I don't think the kernel has a session concept that corresponds to the session concept of PAM or systemd. (Yes, PAM also has sessions.)

It has some sort of sessions for processes, but that is just something sharing the same name, not the same concept.

Re: Systemd Sucks, Long Live Systemd

#155

Post by JdeBP »

tannhaeuser wrote: post #135

Best thing of systemd is that it's putting people behind alternate systemd-free Linuxen. Devuan, Alpine, Gentoo, Void (and particularly the BSDs) come along nicely. I can tolerate systemd on desktops as long as I don't have to deal with it. The moment it craps out with Java-esque error traces in binary logs I'll install Slackware (or is there a modern desktop Linux without systemd I'm not aware of?). Other than for d…

It's 10 lines of shell code to do it badly. Poor Man's Dæmon Supervisors written as shell scripts are inevitably flawed in one way or another. It is, however, easy to do with one of the many toolsets that have been around since the 1990s for doing this.

* http://jdebp.eu./FGA/daemontools-family.html

One of the exhibits in the systemd House of Horror results from people taking multiple Poor Man's Dæmon Supervisors written badly in shell script, nesting them inside one another, nesting the result inside another service manager, and then recommending against service management in toto because this madness goes badly wrong.

* http://jdebp.eu./FGA/systemd-house-of-horror/wso2.html

Re: Systemd Sucks, Long Live Systemd

#156

Post by gens »

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…

Of course nobody benchmarked. Rarely are there programmers in OSS these days that benchmark anything. (not nearly as common as those who claim "speed")

There was a bug though where the journaling was so slow it caused the whole server to crash. (sorry, can't find it right now; something about them using mmaped files and the access pattern was.. or something, interesting stuff:)

Binary logs should be faster, in theory, and should/could be as robust as text logs (if not more), in theory. edit: note that GNU grep is insanely optimized.

Re: Systemd Sucks, Long Live Systemd

#157

Post by tyfon »

krylon wrote: 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…

I'm a bit more on the positive side. I actually really like systemd. When it was first introduced I spent 10-15 minutes learning how it operated and after that it has been so much better than the old init systems.

And the best part is that it's on all the major distros so I don't have to keep relearning the init system if I try something new.

My guess has been that the majority of users enjoy it and a few very vocal opponents have such hate for anything new that they will latch on to every small bug as if it's the worlds end.

(Anecdotally, this is the first time I have written a comment about systemd as other discussions have been non-productive flame fests without substance).

Re: Systemd Sucks, Long Live Systemd

#158

Post by marios »

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.

systemd works somewhat ok for me, because I decided to stick to a very limited subset of the functionality it attempts to provide.

I've also used runit (which follows the daemontools model) as a service manager and I've never had an issue with that. I may just have been lucky though.

For me systemd fails because of some bugs I have repeatedly experienced: - systemd stops reaping zombies for some reason; the OS's PID table becomes full and it's impossible to create new processse -> need to hard reset the machine - systemd overtakes halt/reboot commands which is ok when it works I guess -- but for some reason I sometimes get "operation timed out" (likely because of some bug in systemd or dbus). At this point I have to hard reset the machine to get back to a usable OS.

Imagine if #2 happens to you on a remote machine. In my case, I had to call someone and ask them to reset the machine.

#1 is unthinkable for me, because it's the second thing init is supposed to do (the first one being bringing up the various services). I've never had this happen to me on older Linux or other Unices because let's face it, it's not that hard to do. At that point I honestly thought "how can I expect systemd to provide all the features it boasts when it can't do the easy things well ?".

I've also had daemons that systemd lost track of, apparently because of a wrong setting in the .service file. Now that's not a systemd bug, but it was very difficult to debug because I couldn't "trace" the process starting. On the other hand, with daemontools/runit it's quite simple: manually execute the ./run script and see where it fails. With classical init, run the /etc/init.d/service with sh -x and you see exactly where it fails.

Re: Systemd Sucks, Long Live Systemd

#159

Post by JdeBP »

srslack wrote: post #64
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…

You'll find that there's pretty much nothing you can't outright disable, except for journald. journald needs to be running, but you can turn off the binary logging and redirect everything to syslog. systemd itself is a collection of system daemons, as well as small programs to interact with those daemons, and almost all of them are disabled by default. That's my experience on Arch, and they adhere strictly to upstrea…

> you can turn off the binary logging

Every time that people write that they tell other people who do know systemd that they do not know it. The journal cannot be turned off. Making it be stored in files in /run/log/journal/ instead of in files in /var/log/journal/ is not turning it off. It's making it non-persistent so that it doesn't last across system restarts, delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities. Ironically, making it not be stored in any files at all would actually prohibit the post-processing services from working, as they would have nothing to read and to process into their own formats.

* http://unix.stackexchange.com/a/332315/5132

Re: Systemd Sucks, Long Live Systemd

#160

Post by JdeBP »

lisivka wrote: post #54
djsumdog wrote: post #21

Earlier quoted context omitted.

I don't feel they should. These are arguments I haven't heard before either and I'm glad to see more of these weird cases laid out. I run Gentoo (OpenRC) and Void (Runit) on my own systems, and although I do like both of them, I find the total lack of alternatives to the systemd ecosystem troubling. As a package maintainer, I do like being able to create rpms/deb files and only needing one standardized init script, s…

Why not to write generator of init scripts from Systemd unit files? Unit files are well documented for typical options and are easy to write.

Ahem!

* http://jdebp.eu./Softwares/nosh/worked-example.html

* http://unix.stackexchange.com/a/200281/5132

* https://www.mail-archive.com/supervision@list.skarnet.org/ms...

Post reply on HN