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

71–80 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#71

Post by jcrites »

felixgallo wrote: post #62
jcrites wrote: post #44

Earlier quoted context omitted.

PrivateUsers= is documented in the manual page for systemd.exec [1]. I hope the section I linked will answer your question, but for the sake of simplicity I edited my comment to use PrivateDevices= as the example instead. https://www.freedesktop.org/software/systemd/man/systemd.exe...

You missed the point completely, I'm afraid. The point was that it's a leaky abstraction composed of half implemented concepts that devs have to add to their brain. It does not replace the existing functionality or improve it.

Respectfully, actually, I think you missed the point. Linux itself offers a number of powerful features such as namespaces to isolate programs, capabilities that can be dropped, etc., including the User Namespace feature we're discussing presently [1].

Systemd's job and goal is to provide a simple configuration file format that makes it easy to enable these features with installed system daemons.

You may overlooking the parameters supported by systemd and their benefits. Admins get a single way to manage their services and dependencies, and a way to do that that works consistently across all services. These features can be enabled even if the services were not designed for it (e.g., chroot). With systemd you can employ these settings from the outside with any service, and that's a big advance. Difficult to achieve otherwise.

> The point was that it's a leaky abstraction composed of half implemented concepts

I am unclear what part you want to criticize. The Linux kernel is what provides the User Namespace feature. Systemd helps users take advantage of it. What part do you consider half-implemented or a leaky abstraction?

Please also consider whether you might have the wrong mental model for the feature or its employment. In particular, the documentation for PrivateUsers= says: "This is useful to securely detach the user and group databases used by the unit from the rest of the system, and thus to create an effective sandbox environment." The usage you had in mind when you wrote your comment may not be compatible with the purpose of PrivateUsers. I recommend reading up systemd.exec params [1] before criticism. PrivateUsers= is intended for scenarios like transient sandboxed environments, so I'd suggest we discuss a simpler example like PrivateDevices=

[1] http://man7.org/linux/man-pages/man7/user_namespaces.7.html

Re: Systemd Sucks, Long Live Systemd

#72

Post by astrodust »

alyandon wrote: post #56

At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I'm more familiar with it it has begun to grow on me. There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what…

The idea of systemd isn't bad. What's annoying is the friction involved in using it.

It's just a shade too ornate, a little too magical, in both cases only by a small degree, but it's an important one.

Creating a workable systemd init script is actually pleasant. Getting it running is easy. Checking for errors with status is nice, but searching the logs is annoying.

pm2 (https://github.com/Unitech/pm2) has a neat feature where you can watch logs easily, someting that systemd should totally steal and pack into journalctl, like "systemctl logs sshd" shows it in real-time, an alias to the obnoxiously verbose "journalctl -u sshd -f"

Re: Systemd Sucks, Long Live Systemd

#73

Post by takeda »

alyandon wrote: post #56

At first I didn't care much for the idea of having to learn yet another init system but as I had to write ansible automation stuff for services on Centos 7 it was kind of required that I have some basic understanding of systemd. I have to say now that I'm more familiar with it it has begun to grow on me. There is something subjectively nice to me about running systemctl status and seeing a nice, clear picture of what…

No it's nice, the biggest issues are IMO two:

* it replaces significant part of the OS and creates a new APIs. It's not really problem of systemd itself, but once other applications start depend on the API you would need systemd to use it. This is especially bad for non-linux systems, like BSD for example, which need to write tools that will emulate such API. It doesn't help that Lennart openly is against any non-linux system so he won't make things easier

* it's buggy, this kind of reminds me of Pulse Audio (also created by Lennart) although eventually things will improve, but it sucks on early versions of RedHat/CentOS 7.

Re: Systemd Sucks, Long Live Systemd

#74

Post by emmelaich »

Esau wrote: post #2

I don't care for SystemD for the same reasons that I don't like MacOS's init system: it an opaque, confusing mess.

Poettering and crew have written an enormous number of excellent blog articles and a great amount of very good manual pages.

So, not sure what you have to do to not be 'opaque'

Re: Systemd Sucks, Long Live Systemd

#75

Post by emmelaich »

_red wrote: post #5
kalenx wrote: post #3

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

I rarely see a bash script more than five lines long which doesn't have at least one bug.

If you disagree with me then post an example and I'll show you the bug in it.

Also, it's not the 90% that matters; it's the 9% that is difficult and the 1% that is crap.

Re: Systemd Sucks, Long Live Systemd

#76

Post by plorg »

secabeen wrote: post #70

I've never particularly liked init systems that restart jobs when they die. Normally, I don't want daemons that crash to restart. They should die, be caught by monitoring and the server bypassed. I would accept a single restart but after that, there's clearly a problem, and the systems should fail, rather than restarting the process again and again and again.

As a single user with a number of personal/hobbyist machines, I actually find systemd annoying to work with for precisely this reason. If a daemon is misconfigured and fails to launch several times in a row, it inevitably triggers the systemd "too many retries" error, after which systemd will refuse to start the daemon until some timeout has expired or the counter is cleared. This makes troubleshooting more difficult and frustrating.

Re: Systemd Sucks, Long Live Systemd

#77

Post by [deleted] »

jjnoakes wrote: post #18
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…

Most of this comment is incorrect.

[deleted]

Re: Systemd Sucks, Long Live Systemd

#78

Post by nictrix »

awinder wrote: post #6

I don't know if I'm just crazy but I did enjoy working with upstart for the brief time that I did, much more so than systemd or initv.

I agree, Upstart was great for most things and was simple to understand. Though I ran into some difficult fork, exec issues for certain processes. I sometimes had to run a wrapper to use upstart, but those seemed to be edge cases.

I'd prefer if we stuck with Upstart and improved on it, though it already seems like a distant dream.

Re: Systemd Sucks, Long Live Systemd

#79

Post by mixedCase »

felixgallo wrote: post #62
jcrites wrote: post #44

Earlier quoted context omitted.

PrivateUsers= is documented in the manual page for systemd.exec [1]. I hope the section I linked will answer your question, but for the sake of simplicity I edited my comment to use PrivateDevices= as the example instead. https://www.freedesktop.org/software/systemd/man/systemd.exe...

You missed the point completely, I'm afraid. The point was that it's a leaky abstraction composed of half implemented concepts that devs have to add to their brain. It does not replace the existing functionality or improve it.

>The point was that it's a leaky abstraction composed of half implemented concepts that devs have to add to their brain.

As opposed to a multitude of implementations of varying quality and functionality for the same concept in each init script that needs it?.

Re: Systemd Sucks, Long Live Systemd

#80

Post by eropple »

lisivka wrote: post #46
kl4m wrote: post #7

Earlier quoted context omitted.

And 90% of that 90% has that tiny modification that is a nightmare to debug.

Use `set -x` or `bash -x script.sh` to trace shell script execution. Shell scripts are easy to debug.

I call this to drop into an immediate repl at the point of invocation in a language that doesn't hate me (Ruby):

     require 'pry'; binding.pry
This is, in fact, 2017. One might call it the current year. The stone knives and bearskins of shell scripting have not kept apace with, like...anything else in our industry. You might be comfortable with them, but that doesn't make it easy, it means you have frayed countless synapses learning it.
Post reply on HN