Linux Kernel Developers Fed Up with Ridiculous Bugs in Systemd | Hacker News Reader

Linux Kernel Developers Fed Up with Ridiculous Bugs in Systemd

phoronix.com

22 pointsmococa16 comments

Please add (2014) to the title.

Very early April 2014...

I wonder why we're seeing this at all, is it relevant?

Instead of down-voting, how about answering the question? :)

Nowadays systemd prefixes all the arguments it reads from /proc/cmdline. This is the correct approach, the kernel owns it's own cmdline, and if other components want to use it they should namespace themselves.

It apparently still interprets the global "debug" flag as well: https://www.freedesktop.org/software/systemd/man/systemd.htm...

This gives me a warmer feeling watching OpenRC boot on my laptop.

One day systemd will become part of Emacs

Lennart is my personal superhero.

It's about ideas, not people.

Sadly, they let it continue.

Systemd's primary selling point is that it has already convinced distros to use it.

It inserts bizarre delays.

It makes debugging harder.

It makes logging harder.

The documentation stinks.

It infects other systems (libvirtd, GNOME) and convinces them that SystemD is a necessary dependency.

In short: SystemD doesn't play well with others. It is not a good citizen.

It may be Stockholm Syndrome but I have come to appreciate systemd-style unit files for services. Being able to say "here's the binary, run it as this user, restart it if it exits" beats copying & tweaking bash scripts which is how I dimly remember sysv init working. Doubtless other more recent init systems have similar capabilities.

Anything to do with systemd logging is a goddamn nightmare though. It loves to tell you that a service has failed to start, but doesn't try to do anything like show you stderr from the process that might help debug.

> It loves to tell you that a service has failed to start, but doesn't try to do anything like show you stderr from the process that might help debug.

It does, actually.

    sudo systemctl status the-service

...prints out the last few lines of the service log.

    sudo journactl -u the-service

...shows you all the logs. You can jump to the bottom if you want and start debugging right away.

Debugging is harder until you get used to systemd but otherwise it's a great improvement over sysvinit. The biggest issue I have is that it's apparently not well-supported inside containers and people recommend supervisord instead.

> It makes logging harder.

journalctl -u or tail your daemon's log file

> The documentation stinks.

It's actually pretty decent, and once you dig through it a lot of the unit file properties are genuinely useful and solve real problems that shell scripts can't deal with.

> It inserts bizarre delays.

Like what? Nowadays all distros boot pretty fast with it.

I didn't say sysvinit was better, although it frequently is. There are other inits and daemon supervisors out there.

journalctl is a terrible interface.

As for delays: you've never seen "waiting for [thing]... 5 min 30s" before? You're lucky.

That's terrible but it's just a two line fix; one of the first things I do on any new system.

What's bad about journalctl?

Reply on news.ycombinator.com