4 ms·

Inaccurate information in the man pages doesn’t help. The one for resolved.conf claims that, if the DNS entry is not present in its configuration, systemd resol

Inaccurate information in the man pages doesn’t help. The one for resolved.conf claims that, if the DNS entry is not present in its configuration, systemd resolved will use the DNS servers in /etc/resolv.conf. But using strace showed me that, in fact, it is ignoring that file and using the resolver provided by my ISP (as resolved’s status output confirms). After copying the entries (for 8.8.8.8 and a few backups) into resolved’s configuration, it’s doing what I want it to, now. I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works.

fao_ 6y ago
> I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works. Which is... precisely what a lot of people were worried about re: systemd :(
- zamadatix 6y ago
  I'd say the vast majority of systemd makes things more consistent and easier to understand how something is working at a glance. For some reason resolved in particular is one of the pieces that happens to have a wacky take on the service implementation choices ON TOP OF all of the other services that want to make things "just work" screwing with "how it's supposed to work". If it were just resolved or just the other tools doing wacky things DNS stuff would be a lot less messy to configure.
- LukeShu 6y ago
  As one of the people assembling distros: If you think things are byzantine with systemd, you should have seen how things were before!
  - salawat 6y ago
    Deterministic, and not as prone inexplicable flakiness?
    - LukeShu 6y ago
      I don't know about deterministic, but there's something to the flakiness. The old stuff was byzantine, but it was decades old, which meant that it had decades of people beating on it, figuring out all the ways that it could flake, and fixing those flakes. And that's not something to sneeze at. That doesn't make the old stuff any less byzantine. And systemd really is a lot more coherent than most of what it replaced. But systemd doesn't have decades of people finding all the ways it can fall over.
      - leephillips 6y ago
        I agree. My comment wasn’t a complaint about systemd per se. The old init system was nothing to fall in love with. I think this is an improvement. The problem is that is hasn’t “replaced” all the older mechanisms, but is one more layer that adds to the confusing mess, with sedimentary layers of conflicting systems, mysterious files all over the filesystem, and obsolete and conflicting documentation. What I’ve enjoyed in particular: systemd timers are an improvement over cron; and I’ve been making great use of systemd-nspawn, which is very convenient and powerful.
        narwally 6y ago
        I agree that it is another layer of complexity, but when it works well it's a really good layer of abstraction for user space programs to interact with the kernel. It's only when issues arise that the extra layer brings in more complexity. And like GP stated, that's mostly an issue of time needed to eliminate the most serious bugs and for edge cases to be well understood and documented. there were plenty of growing pains at first, but the transition period for any project looking to replace the old init system was going to be a headache no matter what. It does take some time to grok, and it feels monolithic at first, but I actually think that's a good thing. It's composed of many separate binaries that individually conform to the unix philosophy, but they're all distributed, maintained, and released together. You still have tons of configurations options, but you can be confident that standard systemd components are always going to play nicely with each other. The only issue I've really had are the binary logs. If the indexes get messed up it's a pain to access the logs even if though the actual files rarely have issues with corruption. But it's fairly easy to forward messages to syslog if you need.
matwood 6y ago
Don't even get me started on systemd/resolved. I know the RFC does not give any of the name servers listed priority, but that is how it has been used since inception. Here comes resolved, so now if your first name server ever fails to resolve, it will switch the second and not switch back (unless it also fails). This causes all sorts of issues with private DNS servers on lans, VPCs, and VPNs where you want a failover to a public DNS while resolving. https://github.com/systemd/systemd/issues/5755 https://github.com/systemd/systemd/issues/5755
- JdeBP 6y ago
  Incorrect. https://news.ycombinator.com/item?id=15230795 https://news.ycombinator.com/item?id=15230795
- vetinari 6y ago
  > so now if your first name server ever fails to resolve, it will switch the second and not switch back (unless it also fails) Exactly as it should. > This causes all sorts of issues with private DNS servers on lans, VPCs, and VPNs where you want a failover to a public DNS while resolving. This is broken; you should have per-interface defined DNS. For internal lans, vpns et cetera you can define which zones these DNS servers handle. For public resolvers (designated with handling the ~. zone), just having multiple entries provides the fallback you want.

fao_ 6y ago

> I’ve suspected for a while, and am now pretty sure, that this system has become so byzantine that the (incredibly talented) people assembling distros, writing the software, and maintaining the man pages, don’t know how it works. Which is... precisely what a lot of people were worried about re: systemd :(

zamadatix 6y ago
I'd say the vast majority of systemd makes things more consistent and easier to understand how something is working at a glance. For some reason resolved in particular is one of the pieces that happens to have a wacky take on the service implementation choices ON TOP OF all of the other services that want to make things "just work" screwing with "how it's supposed to work". If it were just resolved or just the other tools doing wacky things DNS stuff would be a lot less messy to configure.
LukeShu 6y ago
As one of the people assembling distros: If you think things are byzantine with systemd, you should have seen how things were before!
- salawat 6y ago
  Deterministic, and not as prone inexplicable flakiness?
  - LukeShu 6y ago
    I don't know about deterministic, but there's something to the flakiness. The old stuff was byzantine, but it was decades old, which meant that it had decades of people beating on it, figuring out all the ways that it could flake, and fixing those flakes. And that's not something to sneeze at. That doesn't make the old stuff any less byzantine. And systemd really is a lot more coherent than most of what it replaced. But systemd doesn't have decades of people finding all the ways it can fall over.
    - leephillips 6y ago
      I agree. My comment wasn’t a complaint about systemd per se. The old init system was nothing to fall in love with. I think this is an improvement. The problem is that is hasn’t “replaced” all the older mechanisms, but is one more layer that adds to the confusing mess, with sedimentary layers of conflicting systems, mysterious files all over the filesystem, and obsolete and conflicting documentation. What I’ve enjoyed in particular: systemd timers are an improvement over cron; and I’ve been making great use of systemd-nspawn, which is very convenient and powerful.
      - narwally 6y ago
        I agree that it is another layer of complexity, but when it works well it's a really good layer of abstraction for user space programs to interact with the kernel. It's only when issues arise that the extra layer brings in more complexity. And like GP stated, that's mostly an issue of time needed to eliminate the most serious bugs and for edge cases to be well understood and documented. there were plenty of growing pains at first, but the transition period for any project looking to replace the old init system was going to be a headache no matter what. It does take some time to grok, and it feels monolithic at first, but I actually think that's a good thing. It's composed of many separate binaries that individually conform to the unix philosophy, but they're all distributed, maintained, and released together. You still have tons of configurations options, but you can be confident that standard systemd components are always going to play nicely with each other. The only issue I've really had are the binary logs. If the indexes get messed up it's a pain to access the logs even if though the actual files rarely have issues with corruption. But it's fairly easy to forward messages to syslog if you need.

matwood 6y ago

Don't even get me started on systemd/resolved. I know the RFC does not give any of the name servers listed priority, but that is how it has been used since inception. Here comes resolved, so now if your first name server ever fails to resolve, it will switch the second and not switch back (unless it also fails). This causes all sorts of issues with private DNS servers on lans, VPCs, and VPNs where you want a failover to a public DNS while resolving. https://github.com/systemd/systemd/issues/5755 https://github.com/systemd/systemd/issues/5755

JdeBP 6y ago
Incorrect. https://news.ycombinator.com/item?id=15230795 https://news.ycombinator.com/item?id=15230795
vetinari 6y ago
> so now if your first name server ever fails to resolve, it will switch the second and not switch back (unless it also fails) Exactly as it should. > This causes all sorts of issues with private DNS servers on lans, VPCs, and VPNs where you want a failover to a public DNS while resolving. This is broken; you should have per-interface defined DNS. For internal lans, vpns et cetera you can define which zones these DNS servers handle. For public resolvers (designated with handling the ~. zone), just having multiple entries provides the fallback you want.