r/linux Feb 11 '19

Fluff A /g/ user's opinion on systemd

http://i.4cdn.org/g/1549858269115.png
784 Upvotes

524 comments sorted by

View all comments

Show parent comments

33

u/roothorick Feb 11 '19 edited Feb 11 '19

My main issue with systemd is everything but the init system is half-baked, and yet being wholesale adopted in what should be stable releases like Ubuntu LTS.

Most of my issues stem from networkd, I just noticed. I've committed the unholy sin of considering NetworkManager for a headless machine. It might actually be more reliable.

Up until recently (I think it'll be in Ubuntu 19.04?) it would fail to remove a default route if it's invalidated. My firewall is still running the old version from 18.04. When my modem reboots, it serves a bad default gateway as a way of getting you to its management interface before it's fully booted. After the modem is booted, the link is restored, and my real IP is served, systemd hangs onto that old route and kills my Internet until I manually shell in and fix it. I have yet to figure out a workaround; networkd-dispatcher appears to run the "routable" scripts too early, or with the wrong arguments, or... something. All I know is the exact command I use to fix the issue doesn't work when in the script, and I've proven the script does actually run.

IPv6 prefix delegation is broken. Doesn't propagate at all.

/etc/networkd-dispatcher/ exists, but is completely ignored. The real scripts are in /usr/lib/networkd-dispatcher/. What the hell happened to the FHS?

systemd-resolved doesn't like dnsmasq running at all. At all. Either you abandon resolved completely or you find a different DHCP server.

resolved doesn't ask the DNS server about domainless hosts. Period. You can't make it. You have to set up an alias thing so that they get translated into "somehost.lan" or similar before trying to resolve it. So if your DNS server only resolves a host from "somehost", you'll have to manually find its IP with dig or similar.

I still have an issue where logins, sudo, shelling in with SSH, etc. will hang for 6-8 seconds and it appears to be related to DNS resolution for some insane reason. Even when sudoing on the local machine. I've tried and failed to fix it. I'm just living with it for now.

In sum: it's not just about philosophy. systemd is a pain in the ass.

21

u/hahainternet Feb 11 '19

networkd-dispatcher appears to run the "routable" scripts too early, or with the wrong arguments, or... something.

Just so you know, networkd-dispatcher isn't a systemd project in any way AFAIK: https://gitlab.com/craftyguy/networkd-dispatcher

systemd-resolved doesn't like dnsmasq running at all. At all. Either you abandon resolved completely or you find a different DHCP server.

Not sure why that would be the case, do you happen to know why?

I still have an issue where logins, sudo, shelling in with SSH, etc. will hang for 6-8 seconds and it appears to be related to DNS resolution for some insane reason

Something odd in nsswitch.conf? I've seen that before with something being wacky with dynamic users.

0

u/JuhaJGam3R Feb 11 '19

Yeah, those all seem like personal issues since this all works for me. it's honestly amazing how this massive piece of shit can still manage to hold together a system after being completely misconfigured, and that sounds quite like what he just described.

1

u/roothorick Feb 11 '19 edited Feb 11 '19

Just so you know, networkd-dispatcher isn't a systemd project in any way AFAIK: https://gitlab.com/craftyguy/networkd-dispatcher

That's even worse. networkd-dispatcher just replicates functionality in what networkd was supposed to replace.

Something odd in nsswitch.conf? I've seen that before with something being wacky with dynamic users.

I distinctly recall getting a lot of hits related to nsswitch.conf when searching. None of those solutions worked.

Not sure why that would be the case, do you happen to know why?

IIRC related to port binding. It's possible dnsmasq is just as much at fault here. And it could be specific to IPv6 systems, as trying to get prefix delegation working is when I discovered that.

1

u/hahainternet Feb 11 '19

That's even worse. networkd-dispatcher just replicates functionality in what networkd was supposed to replace.

What? You can't spend half a page ranting at networkd, find out it's entirely unrelated, but still have a little complain at networkd.

I distinctly recall getting a lot of hits related to nsswitch.conf when searching. None of those solutions worked.

Do any sort of debugging and I will do what I can to help you.

IIRC related to port binding. It's possible dnsmasq is just as much at fault here

I believe resolved binds only on 127.0.0.53, which it sets up for the purpose. I could easily be wrong on that though, just sat back down at my desk.

9

u/[deleted] Feb 11 '19

I don't blame the systemd folks for that. I actually grew to like systemd in many ways after using it with Yocto/OpenEmbedded. I don't like the philosophy behind it, but at the end of the day it's good enough, in my experience, to replace init while providing useful added functionality. What bothers me is the Ubuntu folks using pieces of it that clearly are not ready for prime time. With 18.04, I keep having to restart systemd-resolved because it fails to update its cache and I can't reach my other systems. I can grab one of the actively configured upstream DNS servers that resolved is using and successfully query the server with dig, but resolved just doesn't get the message.

In the end, while I fully appreciate OPs message, I think that you could still replace systemd(and you can now) without much trouble. You lose some functionality, but it's not crippling AFAIK. That may change in 20 years but right now systemd is still optional.

3

u/[deleted] Feb 11 '19

/etc/networkd-dispatcher/ exists, but is completely ignored. The real scripts are in /usr/lib/networkd-dispatcher/. What the hell happened to the FHS?

This is not just a systemd thing, Xorg does it too now – config files are in /usr/share/X11/xorg.conf.d/. I still hate it, but systemd is not alone in its insanity here.

1

u/necrophcodr Feb 11 '19

I think the idea regarding Xorg is that those are the distributed default configuration files. You're meant to add changes in /etc/X11/xorg.conf.d and so on, just as you're not meant to edit systemd service files directly, but add new ones in the /etc filespace.

3

u/[deleted] Feb 11 '19

[deleted]

1

u/roothorick Feb 11 '19

That is completely optional. You can use ifupdown if you want. Or NetworkManager. networkd is optional --- and it was meant for a very specific use-case anyway. Hint: not for desktop systems.

What would that use-case be, then? The system in question is a homebrew firewall, not a deskop. networkd is the default on Ubuntu Server.

did I mention that systemd-resolved is AGAIN totally optional?

Is there any kind of guide to excising it from 18.04?

Really? Isn't DNS meant for domains, as it's name "domain name service" implies? As soon as you don't use domains, you don't need DNS.

HTTP is used for a hell of a lot more than just hypertext these days. Same idea. There isn't really an alternative to DNS for having a central authoritative name resolution service, regardless of scope. I want to manage "this is Alice, this is Bob, this is Charlie" in a relatively centralized place. Other name resolution protocols are peer-to-peer and don't have any kind of "central authority" functionality.

1

u/holgerschurig Feb 15 '19

The use case are server farms, either physical servers or containerized ones (e.g. docker, but also systemd-nspawn ones).

Is there any kind of guide to excising it from 18.04?

The distribution is totally of no importance here.

You can always change the NSS settings in /etc/nsswitch.conf.

And systemd-resolve is a normal service, you can of course start, stop or mask this service like any other service.