Live data from Hacker News

Systemd Sucks, Long Live Systemd

naftuli.wtf

81–90 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#81
post #76

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…

Funnily enough, just dealt with a bug caused by this at work. The small PC would boot before the cellular modem had an Internet connection. Services that communicate via MQTT would immediately attempt to reach the broker, and throw an exception. My quick fix was just to add "RestartSec=5" so that the faulted state would never be entered.

Re: Systemd Sucks, Long Live Systemd

#82

Why 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

#83

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

I keep forgetting why I hate systemd (and as a FreeBSD user for all things, I have never used it) and then an article like this reminds me ... binary logs.

Seriously - just reading it is painful. binary logs

That's a lot of things, but it ain't unix.

Re: Systemd Sucks, Long Live Systemd

#84
post #73

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

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

I'm interested to hear how you got the impression that systemd is/was buggy. I have run systemd on a variety of systems, including pre-systemd-support Debian a few years ago; I was always shocked by how reliably it would bring up the system, consistently name the devices, and provide a convenient interface to the logs.

I have been running systemd consistently on my workstations since Archlinux shipped it in 2012, and I have never run into a bug or poorly-documented feature as long as I have been using it.

Re: Systemd Sucks, Long Live Systemd

#85

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.

[deleted]

Re: Systemd Sucks, Long Live Systemd

#86

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 concerned, I'm happy that it's a single repository tracking consistent, interoperable versions of each of the systems in systemd. This means that there are few dependencies to track.

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.

Re: Systemd Sucks, Long Live Systemd

#87
post #83

Earlier quoted context omitted.

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

I keep forgetting why I hate systemd (and as a FreeBSD user for all things, I have never used it) and then an article like this reminds me ... binary logs. Seriously - just reading it is painful. binary logs That's a lot of things, but it ain't unix.

Meh. You get used to journalctl awfully quickly. For someone who never uses it, it's going to have some friction. You need to remember the command and how to spell it, which I'll admit isn't trivial compared to "just dig around in /var/log" style we're all used to. But you get over that hump in an hour.

For the straightforward "?!$! something happened just grep for it in the log file" it's no harder or slower. And you start noticing things like -f and --since that have no good analogs in the text log world, and it seems like it has value.

And every once in a while you need to pull magic like "show me EVERYTHING that was happening in the 3 seconds before this event, including kernel logs", and that's where it actually makes sense.

I hated it too when I started using it. I don't mind so much now.

Re: Systemd Sucks, Long Live Systemd

#88

I feel like at some point, news aggregation sites will need moratoriums on this topic. Systemd is an architectural decision with very philosophical effects, so by its very nature be very divisive. I'm, personally, not a fan at all of systemd, but am tired of seeing these stupid arguments everywhere all the time. There are plenty of places to find competent summaries of both the technical and political arguments for a…

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…

Where systemd is complex, it's because the use case is complex. If you know so much about these use cases, and you think systemd is unnecessarily complex, why don't you do it yourself and see where that takes you?

Re: Systemd Sucks, Long Live Systemd

#89
post #45

Earlier quoted context omitted.

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

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.

Re: Systemd Sucks, Long Live Systemd

#90

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

Both you and OP haven't mentioned why you needed to do it inline as opposed to in an external script, though.
Post reply on HN