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

161–170 of 272 posts

Re: Systemd Sucks, Long Live Systemd

#161

Post by tannhaeuser »

JdeBP wrote: post #155
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 wr…

You certainly have a point re bad shell scripts. But imho advocating a wholesale service manager monolith like systemd isn't the answer (fallacy of the excluded middle and all).

Unix admins must come to learn what they're doing somehow. The way they learn it is by going one step after another, beginning with simplistic shell scripts controlling isolated functionalities, then improving it etc. Do one thing, and do it well, Unix philosophy, whatever. For novice Unix admins, systemd is too much of a black box, without any kind of didactic curriculum leading to it or away from it. Folks cannot grow into becoming a senior Unix admin.

I've seen it first hand just recently where a customer of mine went all-in (on puppet in this case). The "admins" were merely clicking around and doing trial and error kind of things; they had absolutely no idea what they're doing, and when things are going south won't be able to even diagnose what's going on. They hated their job and went out the door at 5pm. They stayed and were very eager to learn, however, when I gave them an ad-hoc Unix command line survival guide.

Systemd and its ilk is not how you get responsible and competent Unix admins that take pride in their work.

Re: Systemd Sucks, Long Live Systemd

#162

Post by JdeBP »

bazurbat wrote: post #109
chubot wrote: post #59

Earlier quoted context omitted.

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

> Bash with it's multitude of annoying quoting and field splitting rules

So don't use the Bourne Again shell. After all and to start with, if you live in the Debian or Ubuntu worlds, your van Smoorenburg rc scripts have not been using the Bourne Again shell for about a decade.

There's no reason at all that run programs need be written in any shell script at all, let alone in the Bourne Shell script. Laurent Bercot publishes a tool named execline that takes the ideas of the old Thompson shell ("if" being an external command and so forth) to their logical conclusions, which is far better suited to what's being discussed here. One can also write run programs in Perl or Python, or write them as nosh scripts.

* http://blog.infinitenegativeutility.com/2015/2/celebrating-d...

Re: Systemd Sucks, Long Live Systemd

#163

Post by marios »

microcolonel wrote: post #84
takeda wrote: post #73

Earlier quoted context omitted.

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

I think inotify is broken. If 'broken' is too strong a word, then it's at the very least misnamed.

It stands for inode notify, except there are edge cases where it doesn't actually report inode events. Consider this scenario:

  cd /tmp
  mkdir test
  touch test/somefile
  ln test/somefile linktothefile
  inotifywait -m test
Basically, you're monitoring a directory that contains a single file. There's also a hard link to the file, but it's outside of the watched directory. Since it's a hard link, they have the same inode number (you can verify this with ls -i).

If you append data to the file using the "test/somefile" reference, inotify reports the events as expected. If you do the same through the hard link, you get nothing. IMO this is wrong since you accessed the inode. inotify is more of a "report events on a file/directory" rather than a "report events on inode" mechanism.

Re: Systemd Sucks, Long Live Systemd

#164

Post by Xylakant »

dijit wrote: post #134
nvarsj wrote: post #132

Earlier quoted context omitted.

I'm not sure how you could write this with a straight face. Systemd has friction, but writing init scripts doesn't? Are you kidding me? Have you ever had to write init scripts for production servers? Writing systemd unit files is entirely more straightforward and simple than any init script hackery. And how is "journalctl -u sshd -f" not straightforward? Systemd has its issues sure, but your comment is pure FUD.

Writing init scripts is as hard as you want it to be. and 99% of sysadmins are not writing their own, they're modifying the ones supplied by distro maintainers. If you're a distro maintainer then init scripts are something you write, something you understand because you're handling the state of your distribution from them. Of course you can just abstract away all the code to another bash script and have your init as…

> and 99% of sysadmins are not writing their own, they're modifying the ones supplied by distro maintainers.

and even here, systemd makes things easier, more straightforward and comprehensible by allowing to modify system-provided units via drop ins. No need to copy, I get updates to the original units as I'm supposed in a clean and well-defined fashion.

Re: Systemd Sucks, Long Live Systemd

#165

Post by rkangel »

microtonal wrote: post #152
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…

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

This is a reasonable criticism of systemd. The other points seem mostly to be a criticisum of the various distro implementations that use systemd. The sort of thing that gets tidied up over time anyway.

Re: Systemd Sucks, Long Live Systemd

#166

Post by krylon »

digi_owl wrote: post #150
noinsight wrote: post #142

Earlier quoted context omitted.

> a big wadded up ball of code. To be clear, they're all under the same umbrella project, but separate components and not everything is in PID 1. People seem to be confused by that.

Plenty of the "separate" components share core code at compile time. If they were truly separate they could be downloaded piecemeal and compiled independently.

OTOH, sharing code between different components developed under an umbrella project is not bad per se - if they require the functionality, re-implementing it from scratch for each component would not be a good idea, either. Duplicating and manually syncing the code also has its share of problems.

Re: Systemd Sucks, Long Live Systemd

#167

Post by srslack »

JdeBP wrote: post #159
srslack wrote: post #64

Earlier quoted context omitted.

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

>they tell other people who do know systemd that they do not know it.

I appreciate the concern, thanks.

>The journal cannot be turned off.

The persistent binary logging is turned off, which is what people bitch about. Obviously, many of systemd's monitoring features are tied to the journal, and as stated journald still needs to be running, obviously writing to a non-persistent journal for these and forwarding logs (if specified.)

>delegating the job of writing persistent logs to post-processing services that (nowadays) read the journal using its systemd-specific database access facilities.

It's true that syslog-ng pulls messages from the journal, whereas syslog implementations that are not aware are provided with them over a compatibility socket, but this is a performance optimization, to reduce system overhead. Not really an important distinction.

The context was turning persistent logs off and switching to on-disk and persistent text logs with syslog. If you really wanted to nitpick: dbus and udev are totally non-optional.

Re: Systemd Sucks, Long Live Systemd

#168

Post by Fnoord »

ajross wrote: post #87
rsync wrote: post #83

Earlier quoted context omitted.

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

> For someone who never uses it, it's going to have some friction.

Remember some people never used the previous init and logging systems. They're new to Linux or UNIX, they may be even young (and growing up with Systemd).

Not just in this particular case but more broadly it is important to note there's going to be opponents who are used to X, Y, and Z and don't want to relearn or adapt. It is akin to the never ending progressive vs conservative argument. Just how large is the group though? Is there backwards compatibility? You see, I just use 3 Raspberry Pi's and I am apparently still able to use /var/log.

Re: Systemd Sucks, Long Live Systemd

#169

Post by pawadu »

microtonal wrote: post #152
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…

I think systemd would benefit from a slower adaptation.

The network and boot issues that practically everyone have encountered are mostly due to incorrect default configurations. This shows that the maintainers are not ready to use systemd as they don't yet fully understand it.

Re: Systemd Sucks, Long Live Systemd

#170

Post by JdeBP »

skissane wrote: post #63
jjnoakes wrote: post #50

Earlier quoted context omitted.

Most of the statements aren't really conducive to rebuttals because they are lacking substance. But I can imagine what xenadu02 might have meant, if you like, and provide some counter arguments. Signals aren't "garbage" (whatever that means). Signals can call APIs (the set of async-signal-safe APIs). They can't call non-async-signal-safe APIs not because of threads, but because signals can interrupt a routine at any…

I'm not going to defend everything xenadu02 said, but I think there were some points that resonated with me even though I agree they could be expressed more constructively. > Why does ls do sorting? Why does grep do -R recursive searching? How is that "Do one thing and do it well"? I think these are valid examples of how Unix itself fails to follow the "Unix philosophy" of "Do One Thing and Do It Well". > The fork/ex…

The Windows NT model built on operating systems design thought that happened in the 1980s, that took far too many years to trickle into the other operating systems whose designs such thought was looking at.

However, FreeBSD has had process descriptors since roughly 2010. They have the slightly odd semantics of terminating processes when all descriptors to them are closed. But they can be used as descriptors with kqueue() and the like.

Post reply on HN