Comment by vetinari | Hacker News Reader

Comment by vetinari | Hacker News Reader

Parent Full thread

> put symlinks all over the filesystem for all kinds of units. It is less understandable and manageable.

It is actually way better understandable and manageable: /usr/lib/systemd is for distro-supplied and packaged units. /etc/systemd is for your local overrides, /run/systemd is for units created at runtime by various generators. (Then there are $XDG_(RUNTIME|CONFIG)_DIR/systemd for user units, for consistency).

So no more diffing config files at update time: the distro provided ones are always updated, your overrides are always preserved, cleanly.

> - binary log files. everything has to go through systemd to access them.

So send them to external syslog, that saves them as you wish. There is a point in indexing them (and being able to have a newline in the log message).

- responsibility creep

This is a matter of perspective. If you take it as "init system at boot", then yes, it might looks so. If you take as an service manager that runs/stops/reloads/monitors units, based on different events (startup, dbus activation, socket activation, timer, etc): what's the difference in the bulk of action, except for the event that caused that action? The service handling, unit definition, etc. are all the same, just the initiation event is different. In this light, it doesn't take over functions; it consolidates and unifies them.

Unlike dnsmasq or busybox, it is not in cut-down fashion, but exactly opposite. It replaces rag-tag of tools with one with more complete and tested implementation.

> Unlike dnsmasq or busybox, it is not in cut-down fashion

check out for systemd networking, the resolver, timesyncd, etc...

for example timesyncd IS cut-down and brute-force:

"does not bother with the full NTP complexity, focusing only on querying time from one remote server and synchronizing the local clock to it"

ntp is complex, but it does many things in safe and effective ways.

etc.

systemd-network is cut-down I agree. But it does not have an ambition to replace NetworkManager; it is usually installed only in cut-down environments (containers; ubuntu installs it for servers, but not for desktops). Redhat doesn't even have it in repo.

systemd-resolved, on other hand, is good. There's no other resolver stub, that has the functionality that resolved has. It is the only one for Linux, that can do per-link, split DNS properly.

I recall systemd-resolved ignoring the resolv.conf order of preference of name servers. The native and thus relatively simple per-link DNS configuration is great though.

Addendum: https://news.ycombinator.com/item?id=15228940 This approach clearly deviates from widely expected behavior, whether it is in conformance with applicable RFCs or not.

Resolv.conf does not specify order of preference of name servers! All the servers configured here are supposed to return the same answers!

See, many people have misconceptions how it works; see the comments in thread you linked to. Add to it the fact that resolv.conf syntax cannot express what is expected of modern resolvers (not even with apple-like extension - `/etc/resolver/*`; it cannot react to links going up and down), it is basically just compatibility shim for broken applications (they are not supposed to use it directly); that's why systemd-resolved configures it to point to itself and handles the specifics for them.

Providing the same answers does not preclude an order (of preference). The man page clearly shows that such an order exists, though it does not explicitly label it as a preference. Whether you think it's right or wrong is irrelevant—the fact remains that the expectation of querying DNS servers in a specific order has been a common understanding for many. You're free to think systemd-resolved is the right way forward, but that's not an argument against the existence of the ordering in resolv.conf.

> the fact remains that the expectation of querying DNS servers in a specific order has been a common understanding for many.

That understanding has been wrong; it is an implementation detail of glibc and that's it. It could query them in random order, or round-robin them for each request; or time them how fast they respond and prefer the fastest, up until it starts timing out and then shake the order again. Some resolver stubs ask all of them and use the answer that arrives first. That's also valid. Since they all are returning the same answer, it doesn't matter. It also makes any argument for ordering superfluous.

So that "common understanding for many" is erroneous and those many should update it. The thread you linked to has exactly a discussion on this point, so in the years that passed since then, those affected many had ample time to fix up their assumptions.

That understanding is in line with using libresolv and the established behavior of the resolv.conf file, which accompanies the libresolv library. While it’s true that different implementations (e.g., some resolver stubs) might use various methods like round-robin, timing, or querying all servers simultaneously, this doesn’t invalidate the behavior outlined in resolv.conf.

Again, there can be other valid reasons for maintaining an order. Could be about latency, privacy etc.

I admit to not having read the full thread, and I apologize for any needless rehashing of arguments. It was just the first result confirming systemd-resolved breaking setups by its handling of what many (in that thread) consider expected behavior.

What I think you're primarily suggesting is that there are no formal standards prescribing glibc's behavior in terms of DNS resolution order. That is certainly true, and I don't disagree calling it an implementation detail.

Reply on news.ycombinator.com