Re: bind9 startup problems: /var/cache /bind
I tested my suspicion that bind9-resolvconf was somehow implicated in the bind9 start problems by returning bind9-resolvconf to its original, disabled, state and restarting the system. Unfortunately, it didn't help: May 25 19:05:34 barley named[804]: /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' failed: file not found But at least one theory has been eliminated. I also reviewed permissions and ownership of /var/cache/bind and the "directory" directive in named.conf.options for consistency with Debian post-install scripts and packaged files. There weren't any differences. Ross
Re: bind9 startup problems: /var/cache /bind
On Wed, May 22, 2019 at 2:47 PM Richard Hector wrote: > > RequiresMountsFor=/absolute/path/of/mount > > .. to go in the unit file - or IIRC running: > > sudo systemctl edit bind9.service > > ... and putting in: > > ---8< > [Unit] > RequiresMountsFor=/var > ---8< > > ... followed by: > sudo systemctl daemon-reload > Thank you for the very clear instructions. I wish README.Debian for systemd said how you're supposed to handle /etc, since it's somewhat non-standard. I tried it. Unfortunately, it didn't work. After rebooting I still get -- May 22 18:38:49 barley named[829]: loading configuration from '/etc/bind/named.conf' May 22 18:38:49 barley named[829]: /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' failed: file not found May 22 18:38:49 barley named[829]: /etc/bind/named.conf.options:2: parsing failed: file not found May 22 18:38:49 barley named[829]: loading configuration: file not found May 22 18:38:49 barley named[829]: exiting (due to fatal error) Again, when I restart the service it succeeds. As a check to see if my options took, systemctl show bind9 does have the lines (leaving in some resolvconf stuff because of my suspicions): - Requires=sysinit.target -.mount var.mount system.slice Wants=nss-lookup.target bind9-resolvconf.service ConsistsOf=bind9-resolvconf.service Before=bind9-resolvconf.service multi-user.target shutdown.target nss-lookup.target After=basic.target system.slice -.mount systemd-journald.socket sysinit.target var.mount network.target RequiresMountsFor=/var --- Finally, ls -ld /var/cache/bind drwxrwxr-x 2 root bind 4096 May 22 16:50 /var/cache/bind The manual restart of bin began just before 18:50 local time. Ross
Re: bind9 startup problems: /var/cache /bind
On 23/05/19 9:08 AM, Ross Boylan wrote: > /var is a separate file system, and like / it's encrypted, so it might > take a bit of time to activate it. Whether it's available when > needed, I don't know, though the error suggests it might not be. > Could systemd be launching services while some of the mounts (and the > required decryption) are still to be done? > > Is there some systemd way to ensure the file system is mounted before > launching bind? But I'd think if /var weren't available, bind > wouldn't be the only one with a problem. Well, I don't see anything in bind9.service to prevent it starting. I'm not sure what the best dependency is ... A bit of web searching finds: https://unix.stackexchange.com/questions/246935/set-systemd-service-to-execute-after-fstab-mount ... which suggests: RequiresMountsFor=/absolute/path/of/mount .. to go in the unit file - or IIRC running: sudo systemctl edit bind9.service ... and putting in: ---8< [Unit] RequiresMountsFor=/var ---8< ... followed by: sudo systemctl daemon-reload Not tested. Cheers, Richard signature.asc Description: OpenPGP digital signature
Re: bind9 startup problems: /var/cache /bind
/var is a separate file system, and like / it's encrypted, so it might take a bit of time to activate it. Whether it's available when needed, I don't know, though the error suggests it might not be. Could systemd be launching services while some of the mounts (and the required decryption) are still to be done? Is there some systemd way to ensure the file system is mounted before launching bind? But I'd think if /var weren't available, bind wouldn't be the only one with a problem. Ross
Re: bind9 startup problems: /var/cache /bind
On 23/05/19 8:00 AM, Ross Boylan wrote: > At system start, bind9 fails to start on a recently created buster > system. Some of the local bind is based on configuration from an > earlier bind. The logs show > /etc/bind/named.conf.options:2: change directory to '/var/cache/bind' > failed: file not found > > But if I then start it manually via systemctl, it starts. But then I > need to fix up other services which were counting on working name > resolution when they started. Is /var/cache (or /var) a separate filesystem, that might not be mounted in time at boot? Richard signature.asc Description: OpenPGP digital signature
