Hacker News Reader

Comment by thehardsphere | Hacker News Reader

I stopped using Linux for personal before this systemd thing was an issue, but I was considering it again now that I might get a new computer and because I've got an app running on a pre-systemd Linux VPN. Since I have very little first hand experience with systemd, I have some questions.

1. Is it actually that bad for a desktop?

2. Is it actually that bad for a server?

3. If yes to either, how suitable are the alternatives (e.g. Gentoo, Slack, or BSD)?

View on HN

> 1. Is it actually that bad for a desktop?

As a desktop user, systemd has been a godsend. Now everything works the same on every distro. No more checking the website of each distribution to know where to put stuff if you want them to run on boot.

I also migrated everything in my computers to systemd-networkd and systemd-resolved and systemd-timesyncd and it is just so fast and always work reliably (again, for a desktop usage).

journalctl is fantastic: now every single line of log has the same format that every other, and you can filter exactly which service outputted which log line at which time. VS the old way where you would always have that rebel service that logged stuff in whatever format that would always break the grep command you'd be trying to write.

My answer may not be satisfying, as I was never much of an init guru - never bothered much with configuration.

But here are my systemd observations:

- log files now are binary and accessed by `journalctl` - it's a bit less convenient than looking for text files in `/var/log`

- unit files are a miracle. For the 7 or so years before systemd, I wrote one unportable init script, and I hated it. Now I churn them out whenver I feel like it - they are standardized and the docs are incredible.

Apart from that, nothing really changed from my POV, and I use systemd on desktop as well as in small servers.

For the log files, one miraculous thing you can do is `sudo journalctl -f -u httpd -u mariadb`, which watches the log for both of those services (and should output messages in the correct order). On a desktop, the way it's designed should make the system log viewer (if you need it) quite a bit faster and cleverer, since the stuff we used to do with grep or with extra tooling is just kind of built in to the format.

Another handy set of tools are the time-based queries, like "journalctl --boot" for logs since the last reboot, or "journalctl --since 16:30" to see logs since that time. (Which can also be specified in relative terms, like "-30m" for the last half hour.)

To add on another handy trick, `journalctl -o cat` or `-o short` will output less information. It's a simple thing, but it's something I use quite often and I don't think everyone knows.

> - it's a bit less convenient than looking for text files in `/var/log`

I find it more practical to be able to filter logs in any way I want (get everything that concerns this device or this service or this user) rather than in a single way.

It's very good on both desktops and servers. I was an old-school sysadmin for a large, non-cloud Linux datacenter deployment that migrated from Debian 7 to 8 last year, and I am now super mad when I have to deal with servers that don't have systemd. Having consistent service startup and not getting things in my environment leaked into /etc/init.d/whatever start is amazing. Being able to register custom services and have them hook into the existing system with about 5-10 lines of config is amazing. `journalctl -u foo` to see just the logs from foo.service is amazing.

Yes, there are other systems that do all these things, but having this actually be implemented out-of-the-box is one of the amazing things too.

(Note that this is different from saying that systemd is flawless code or that I agree with the systemd maintainers' approach to everything. I do actually have a good number of disagreements. But they've made a working system that solves real problems.)

If you have to ask, you probably don't care.

If it was that bad for the average consumer, the major mainline distros wouldn't have all adopted them.

I don't care today; I don't have a daily driver using this stuff today. I care for my future self who might have to deal with this.

It was my understanding that the major mainline distros adopted it because Red Hat coerced Gnome into adopting it, and everyone feels the need to support Gnome.

Systemd was a personal project of Lennart, it didn't even originally came from Red Hat. Red Hat certainly hasn't the power to coerce Gnome into anything.

And major distros all had long discussions and debates on public mailing lists where the details of why they adopted it is discussed.

Pretty much. Originally, the Gnome developers told the distros that it wasn't a big deal because logind would run just fine with whatever init system they chose to use. The a few years later once this was deeply embedded in everything Poettering declared that this was never supported, the distros shouldn't have done it, and it would break in the imminent future. The major distros all switched in the next release whether they wanted to or not.

Various people adopted it for various different reasons, and after going through vastly differing decision processes. Consider the contrast between Debian and Arch, for just one example.

* https://news.ycombinator.com/item?id=11834348

openSUSE has a good page explaining why they use it. https://doc.opensuse.org/documentation/leap/reference/html/b...

Though I agree that it isn't so terrible for most users, your point doesn't follow; to my understanding, systemd was adopted because it made life easier for distro maintainers, not the users.

1/2/3: No, it isn't that bad, but disable resolved and networkd, and coredumps, and prepare to hate journald with all your being because of how insanely mindbogglingly slow it is (owning a hard drive rather than an SSD is an unsupported configuration for journald). The init daemon is much better than init scripts; it isn't elegant, but it is at least declarative and efficient.

Eh, journalctl isn't that bad on a spinning drive. The recent parts of the journal are usually in file cache, so if you use the limiters, like "journalctl --since today" or "journalctl -e"; or view in reverse order "journalctl -r" then things are speedy.

One thing I've seen systemd newbies do that I have to shake my head at is "journalctl | grep sshd" and that's entirely the wrong way to do it.

Considering that the concept is breaking the Unix tradition of a tool having a single purpose and utilizing this fantastic feature we call "pipes"... journalctl is the wrong way to do it.

I don't have enough RAM that journal is usually in cache (just anecdotally, it seems to always be slow the first time in a session that I run it). Nonetheless, I can access most uncached contents of my disk much faster than this:

    $ time journalctl -r | head -n 50
    (...)
    journalctl -r  0,01s user 0,04s system 0% cpu 5,289 total
    head -n 50  0,00s user 0,00s system 0% cpu 5,287 total

If your lifestyle involves embracing the capitalist consumption treadmill of buying new hardware every couple of years, systemd-journald may be for you. Otherwise prepare to be told to throw away perfectly good computer hardware because Lennart is too lazy to design software that can cope gracefully with disk latency.

"journalctl -r" is loading all the available logs on your system. If you only want the most recent 50 lines, use "journalctl -r -n 50".

It certainly isn't; it's killed by SIGPIPE after printing 50 lines. If I wanted to wait for the entire system log to read off of disk I'd be sitting for minutes.

"journalctl -r -n 50" takes 5.4 seconds as of a test just now from (this time, artificially) cold cache.

1) No, on a desktop, you will almost certainly never notice. (I don't, and I've been on systemd-using distributions for some time. It's a workstation, and as long as wake/sleep work, wifi works, and all that jazz, how they work doesn't matter.)

2) No, on a server, I prefer systemd. I write just a small handful of units for services, and it's so so so much simpler to do basic stuff with systemd than trying to put together init scripts to do the same.

My use cases don't depend on a long history of legacy stuff to support, so for me, systemd is simply a win, full stop.

Why was this downvoted? Doesn't appear to be incendiary or insulting, provides a reasonable viewpoint... what, just unpopular for some reason?

People downvote unpopular opinions, even if those opinions are relevant to the discussion and expressed politely. Though that would be strange in this case because it seems like most of the expressed opinions are positive with regard to systemd.

I for one appreciated the opinion, because it answered my question.

Reply on news.ycombinator.com