Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1055139 - nfs mounts fail at boot time if system is also the DNS server
Summary: nfs mounts fail at boot time if system is also the DNS server
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: bind
Version: 20
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Tomáš Hozza 🤓
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-01-19 05:31 UTC by Ed Greshko
Modified: 2014-07-18 10:32 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-18 10:32:31 UTC


Attachments (Terms of Use)
journal showing failure (deleted)
2014-01-19 05:31 UTC, Ed Greshko
no flags Details

Description Ed Greshko 2014-01-19 05:31:09 UTC
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:

Comment 1 Lennart Poettering 2014-06-20 00:41:39 UTC
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!

Comment 2 Ed Greshko 2014-06-20 03:09:57 UTC
I have tested the suggested workaround and it did *not* fix the problem.  :-(

Comment 3 Tomáš Hozza 🤓 2014-06-20 11:20:40 UTC
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

Comment 4 Ed Greshko 2014-06-20 12:33:01 UTC
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.

Comment 5 Tomáš Hozza 🤓 2014-06-20 13:13:14 UTC
(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...

Comment 6 Pavel Šimerda (pavlix) 2014-06-20 13:40:48 UTC
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.

Comment 7 Tomáš Hozza 🤓 2014-07-18 10:32:31 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.