Created attachment 852227 [details] journal showing failure Description of problem: If the fstab defines the nfs server as a hostname and the client system is the DNS server the mounts a boot time will fail since named/bind hasn't started when the mount is issued. Thus, the hostname can't be resolved to an IP address. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a nfs mount in fstab using a hostname for the server 2. Configure named/bind to run locally and set resolv.conf to 127.0.0.1 3. Reboot Actual results: mounts fail at boot time. Expected results: There should be a way to determine that DNS resolution is being done via 127.0.0.1 and nfs mounts should be delayed until named/bind has started. Additional info:
Note sure what to do about this. There might be setups where bind might need resources on NFS to work, and others like yours where NFS requires bind to work. I don't see how we should ever be able to solve this generically... REassigning to bind. Maybe they want to add Wants=remote-fs-pre.target and Before=remote-fs-pre.target to their service file. That way they will fix your case, but break the case where DNS zone files might be on NFS... If I were the bind maintainer I probably would not fix that. YOu can always fix this locally by doing the equivalent of what I say above: mkdir -p /etc/systemd/system/bind.service.d/ echo "Wants=remote-fs-pre.target" > /etc/systemd/system/bind.service.d/mynfssetup.conf echo "Before=remote-fs-pre.target" >> /etc/systemd/system/bind.service.d/mynfssetup.conf And on next reboot thing should work. REassigning. Bind folks, your might or might not to fix this. If not, please close WONTFIX, thanks!
I have tested the suggested workaround and it did *not* fix the problem. :-(
Exactly due to the reason Lennart mentioned in the first paragraph of comment #1 I don't want to hard-code the dependency into BIND's service file. (In reply to Ed Greshko from comment #2) > I have tested the suggested workaround and it did *not* fix the problem. :-( I think the reason may be that BIND's service file is named "named.service" not "bind.service". So please try: mkdir -p /etc/systemd/system/named.service.d/ echo "Wants=remote-fs-pre.target" > /etc/systemd/system/named.service.d/mynfssetup.conf echo "Before=remote-fs-pre.target" >> /etc/systemd/system/named.service.d/mynfssetup.conf
I did.... mv /etc/systemd/system/bind.service.d /etc/systemd/system/named.service.d/ [egreshko@meimei ~]$ cat /etc/systemd/system/named.service.d/mynfssetup.conf Wants=remote-fs-pre.target Before=remote-fs-pre.target rebooted. Still the mounts do not occur at boot time.
(In reply to Ed Greshko from comment #4) > I did.... > > mv /etc/systemd/system/bind.service.d /etc/systemd/system/named.service.d/ > > [egreshko@meimei ~]$ cat /etc/systemd/system/named.service.d/mynfssetup.conf > Wants=remote-fs-pre.target > Before=remote-fs-pre.target > > rebooted. Still the mounts do not occur at boot time. I think it does not work because BIND has AFTER netrok.target, which has AFTER remote-fs-pre.target, so BIND can not be started BEFORE remote-fs-pre.target. So it causes the transaction to fail...
In my opinion, it would be best to require all recursive DNS servers to be able to start before network is started. IP_FREEBIND may help here. Using the same server as an authoritative one with data on NFS is another story. In that case you would need to get the recursive part working at boot time and load the authiritative zones later. Using one service for recursive and authoritative has drawbacks. I can't understand why those two types of services got the same port number.
I did some testing with the environment you've described. If BIND is listening *only* on loopback, removing the After=network.target and adding After=remote-fs-pre.target instead (with Wants) does the trick. However I don't know if it is guaranteed that loopback will be properly configured before remote-fs-pre.target. Maybe Lennart will know more. To make sure it is, you can create a one-shot unit that will execute 'ip link set lo up' and configure named.service to start Before the one-shot unit. So copy the bind package provided unit file from /lib/systemd/system to /etc/systemd/system and do the necessary changes described above. I'm not going to make any changes to the named.service due to this specific use-case as it would break the general use-case (if named listens on addresses other than loopback and does not start After network-online.target, it doesn't bind to them). Closing as WONTFIX.