I think I got bit yesterday by the above... I was noticing terrible resolution speed, so checked messages (btw, "service bind9 status" provides brief, but decent-ish characterization of things), and noticed many messages indicating failing resolutions against IPv6 addresses. There is a common pair of bits of Bind configuration: a) One might set options to prefer not to use IPv6 addresses, so in /etc/bind/named.conf.options, change listen-on-v6 { all;}; to listen-on-v6 { none; }; b) This was where SystemD got into the mix... Pass the "-4" option when running named to use only IPv4. This seems to be the highly significant bit. On Debian-derived systems, the usual recipe is to add "-4" to /etc/defaults/bind --> OPTIONS="-4" However, the SystemD config for Bind9 lives in /lib/systemd/system/bind9.service, and apparently there is recent change there that that configuration no longer reads from /etc/defaults/bind, so that to have named get the "-4" option requires altering /lib/systemd/system/bind9.service. Seems like it needs to be altered directly. This isn't necessarily a "SystemD bug", rather a packaging bug in Debian. It still was fairly annoying. I have yet to report it properly, probably deserves a bit more research, in case my diagnosis is off a bit. -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
I think you might want to follow the advice below so your changes don't get overwritten after next update (Adjust for debian of course): *Q: I want to change a service file, but rpm keeps overwriting it in /usr/lib/systemd/system all the time, how should I handle this?* A: The recommended way is to copy the service file from /usr/lib/systemd/system to /etc/systemd/system and edit it there. The latter directory takes precedence over the former, and rpm will never overwrite it. If you want to use the distributed service file again you can simply delete (or rename) the service file in /etc/systemd/system again. On 16 October 2014 09:59, Christopher Browne <cbbrowne@gmail.com> wrote:
I think I got bit yesterday by the above...
I was noticing terrible resolution speed, so checked messages (btw, "service bind9 status" provides brief, but decent-ish characterization of things), and noticed many messages indicating failing resolutions against IPv6 addresses.
There is a common pair of bits of Bind configuration: a) One might set options to prefer not to use IPv6 addresses, so in /etc/bind/named.conf.options, change listen-on-v6 { all;}; to listen-on-v6 { none; };
b) This was where SystemD got into the mix...
Pass the "-4" option when running named to use only IPv4. This seems to be the highly significant bit.
On Debian-derived systems, the usual recipe is to add "-4" to /etc/defaults/bind --> OPTIONS="-4"
However, the SystemD config for Bind9 lives in /lib/systemd/system/bind9.service, and apparently there is recent change there that that configuration no longer reads from /etc/defaults/bind, so that to have named get the "-4" option requires altering /lib/systemd/system/bind9.service. Seems like it needs to be altered directly.
This isn't necessarily a "SystemD bug", rather a packaging bug in Debian. It still was fairly annoying.
I have yet to report it properly, probably deserves a bit more research, in case my diagnosis is off a bit.
-- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
--- GTALUG Talk Mailing List - talk@gtalug.org http://gtalug.org/mailman/listinfo/talk
On 16 October 2014 12:33, Peter Platek <peterplatek@gmail.com> wrote:
I think you might want to follow the advice below so your changes don't get overwritten after next update (Adjust for debian of course): *Q: I want to change a service file, but rpm keeps overwriting it in /usr/lib/systemd/system all the time, how should I handle this?*
A: The recommended way is to copy the service file from /usr/lib/systemd/system to /etc/systemd/system and edit it there. The latter directory takes precedence over the former, and rpm will never overwrite it. If you want to use the distributed service file again you can simply delete (or rename) the service file in /etc/systemd/system again.
Debian won't silently overwrite the file in /lib/systemd/system/bind9.service (barring doing some particular configuration to do otherwise!!!); an upgrade would notice the difference, and ask if you want to overwrite the changes. Which points at the notion that there's still a problem; if the options are *supposed* to be configurable, they should go some place where they will be referenced, as opposed to there being some question of overwriting things. Hmm. Looks like the customization location *might* be /etc/systemd/system/multi-user.target.wants/bind9.service Yep, that looks mighty promising. If I edit that, and check systemd status ($ service bind9 status), I get the warning that... Warning: Unit file changed on disk, 'systemctl daemon-reload' recommended. [wait a minute... Seems like a closer relationship...] root@cbbrowne:~# ls -l /etc/systemd/system/multi-user.target.wants/bind9.service lrwxrwxrwx 1 root root 33 Oct 16 13:24 /etc/systemd/system/multi-user.target.wants/bind9.service -> /lib/systemd/system/bind9.service Same file... There's a further curiosity; I run etckeeper, to keep the stuff in /etc under SCM control. If systemd config isn't in /etc, it's not "under control" (in more senses than one!). More research warranted! :-) -- When confronted by a difficult problem, solve it by reducing it to the question, "How would the Lone Ranger handle this?"
participants (2)
-
Christopher Browne -
Peter Platek