PDA

View Full Version : F16 fails to mount NFS shares on boot (but no problem from CLI)



droopy4096
12th January 2012, 08:14 AM
I have had working setup with F15, where mounts were listed in /etc/fstab and everything was honky-dory. Seemingly same setup in **freshly installed** F16 doesn't work resulting in timeout during boot. :



...
Jan 11 23:27:09 gamer dnsmasq[2149]: reading /etc/resolv.conf
Jan 11 23:27:09 gamer dnsmasq[2149]: using nameserver 192.168.0.1#53
Jan 11 23:27:09 gamer dnsmasq[2149]: read /etc/hosts - 2 addresses
Jan 11 23:27:09 gamer kernel: [ 30.523539] Ebtables v2.0 registered
Jan 11 23:27:20 gamer kernel: [ 41.632113] br0: port 1(eth0) entering forwarding state
Jan 11 23:28:25 gamer systemd[1]: Job 192.168.0.2:-gateway.device/start timed out.
Jan 11 23:28:25 gamer systemd[1]: Job remote-fs.target/start failed with result 'dependency'.
Jan 11 23:28:25 gamer systemd[1]: Job mnt-gateway.mount/start failed with result 'dependency'.
Jan 11 23:28:25 gamer systemd[1]: Job fsck@192.168.0.2:-gateway.service/start failed with result 'dependency'.
Jan 11 23:28:25 gamer systemd[1]: Job 192.168.0.2:-gateway.device/start failed with result 'timeout'.
Jan 11 23:28:25 gamer systemd[1]: Job 192.168.0.2:-movies.device/start timed out.
...

bit of an explanation on my networking setup - due to my requirements on Virtualization front I've got bridge br0 setup over eth0, and that one is being used as a main interface. NetworkManager is disabled, setup is all done in /etc/sysconfig/network-scripts/ifcfg-{eth,br}0:



--ifcfg-eth0:

DEVICE="eth0"
BOOTPROTO=none
ONBOOT="yes"
NM_CONTROLLED="no"
HWADDR=00:xx:F3:xx:xx:xx
NAME="System eth0"
UUID=5fb06bd0-0bb0-xxxx-45f1-xxxxxxxx

--ifcfg-br0:
BRIDGE=br0
DEVICE="br0"
BOOTPROTO="static"
NM_CONTROLLED="no"
ONBOOT="yes"
TYPE=Bridge

DNS1="192.168.0.1"
GATEWAY="192.168.0.1"
HOSTNAME="foo.bar.com"
IPADDR="192.168.0.100"
MTU="1500"
NETMASK="255.255.255.0"
ONBOOT="yes"
USERCTL="no"

as far as I see it - br0 comes up just fine but for whatever reason NFS mounts time-out/fail (as per log), however when I launch 'systemctl netfs.service restart' - I get all mounts as expected. I have even switched SELinux in permissive mode via /etc/sysconfig/selinux. Still no dice. Did I miss something? Should operating F16 be significantly different from F15 for this particular case?

droopy4096
14th January 2012, 12:09 PM
Today 3 things have happened simultaneously: I ave installed updates. Most of which didn't seem like related to my problem (some wine* packages and boost* stuff). Then I have installed support for additional languages (Russian, Ukrainian, Chinese, French). Then I decided to create "debug" service for systemd "phony.service":



[Unit]
Description=Phony service to debug startup
After=network.service
Before=netfs.service

[Service]
ExecStart=/usr/local/bin/ipstatus
Type=forking

[Install]
WantedBy=remote-fs.target

with local script /usr/local/bin/ipstatus :

#!/bin/sh

(echo "============="; date;) >> /var/log/ipstatus.log
ifconfig >> /var/log/ipstatus.log
netstat -nar >> /var/log/ipstatus.log

And after rebooting machine - it mounts all NFS shares automatically. So far my guess is that "phony.service" is to blame (praise?) as it provides sufficient delay between network.service, ebtables.service and netfw.service for things to settle and for mount to happen. I'll experiment some more and post back.

rossman_2
17th January 2012, 08:54 AM
Your solution is interesting, but (no offense) not very satisfying. I'm having what I believe is a very similar issue. I'm trying to auto mount an nfs share on a system over wifi. I believe the system is trying to mount the remote file system before the wireless adapter has a chance to initialize and connect to my wireless network. The following is my mount script (with the private stuff "x"ed out):


[Unit]
Description="Mount for /home/xxxx/xxxx"
Requires=NetworkManager.service
After=NetworkManager.service

[Mount]
What=lserver:/home/share/xxxx
Where=/home/xxxx/xxxx
Type=nfs4
Options=ro,auto,nosuid,noexec
DirectoryMode=0755
TimeoutSec="2min"

[Install]
Alias=xxxx.mount
WantedBy=remote-fs.target

When I use this script with the "systemctl start" command, it mounts the remote file system. But when I enable this to run on startup, it fails. I'm not really familiar with systemd, so I don't really know how to get more status. I looked at "/var/log/messages" but there didn't seemed to be anything interesting other than it said the mount failed.

Any help anyone could provide would be most appreciated. I really don't like the idea of setting up a dummy service to work out a timing issue.

droopy4096
17th January 2012, 05:04 PM
Actually what you describe fits much better with autofs (automount) scheme more than anything. I actually considered switching my setup to automount as well as it provides certain level of asynchronicity and "on-demand" mount that aleviates other problems associated with NFS mounts. I have done it with CIFS:

http://daemon.makovey.net/2011/12/easy-way-to-mount-cifs-in-fedora-linux-via-autofs/

NFS should not be too different.

jpollard
17th January 2012, 05:20 PM
The problem is systemd.

It needs explicitly stated dependencies for it to function properly, and is EXTREMELY sensitive to timing failures - which is what you have.

autofs MAY work, but only if you don't need the NFS mounts during boot for some chron job you may be running - it will fail (maybe - again, it depends on the timing. If the job runs before the network is up--- autofs will fail).

The problem with "NetworkManager.service" dependency is that the network is not necessarily ready (yet). Especially when multiple interfaces are being initialized. All the NetworkManager.service gives you is that the NetworkManager process is running, not that it has finished initializing the network. Try using "network.target" (I believe that is the name) instead. This is not a real service, but is something that is supposed to block until the network is functional. And try the "after=entwork.target" instead.

One of the bloody problems with systemd is that you HAVE to know every minor need, and without it, the entire thing falls down.

droopy4096
18th January 2012, 02:29 AM
Now I missed the network.target completely. Indeed there are 2 of them: network.service and network.target :


$ systemctl status network.target
network.target - Network
Loaded: loaded (/lib/systemd/system/network.target; static)
Active: active since Mon, 16 Jan 2012 09:51:32 -0700; 1 day and 8h ago
$ systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: inactive (dead)
CGroup: name=systemd:/system/network.service


while I appreciate the goodness that systemd brings it's maturity level (at least in Fedora) obviously is not "there" yet.

More to the point: autofs was designed **specifically** to adress the issues of booting machines with loop NFS interdependancies and such - and cron jobs should work just fine - FS will be mounted as soon as it's requested, however as you (jpollard) imply - if network is down - nothing will happen, but then autofs shouldn't start before network is up ;)

jpollard
18th January 2012, 01:29 PM
Now I missed the network.target completely. Indeed there are 2 of them: network.service and network.target :


$ systemctl status network.target
network.target - Network
Loaded: loaded (/lib/systemd/system/network.target; static)
Active: active since Mon, 16 Jan 2012 09:51:32 -0700; 1 day and 8h ago
$ systemctl status network.service
network.service - LSB: Bring up/down networking
Loaded: loaded (/etc/rc.d/init.d/network)
Active: inactive (dead)
CGroup: name=systemd:/system/network.service


while I appreciate the goodness that systemd brings it's maturity level (at least in Fedora) obviously is not "there" yet.

More to the point: autofs was designed **specifically** to adress the issues of booting machines with loop NFS interdependancies and such - and cron jobs should work just fine - FS will be mounted as soon as it's requested, however as you (jpollard) imply - if network is down - nothing will happen, but then autofs shouldn't start before network is up ;)

It will be mounted if the network is working... otherwise it fails.

It will also work IF name resolution is working... otherwise it fails.

It all depends on how long after boot that the cron entry runs.

Since all services tend to be started simultaneously, you can't be sure that cron waits for autofs to be ready before making the request.

Granted, it usually takes that long... but it is indeterminate unless all SysVinit ordering information has been added to the systemd procedures.

Unfortunately, they haven't. So things still fail.