Dear list,
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are no longer mounted at boot. Claims that the nfs server is not resolvable, but it clearly is. Raised the timeo to 200, but no luck. Hints? Bugworthy?
regards Jens
[root@andrea ~]# systemctl status media-jessa.mount ● media-jessa.mount - /media/jessa Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Sun 2015-02-22 08:52:55 CET; 1min 15s ago Where: /media/jessa What: mavie.zeeroos.int:/media/jessa Docs: man:fstab(5) man:systemd-fstab-generator(8) Process: 1849 ExecMount=/bin/mount -n mavie.zeeroos.int:/media/jessa /media/jessa -t nfs -o _netdev,rw,hard,intr,nfsvers=3,tcp,noatime,nodev,async,rsize=8192,wsize=8192,vers=3,nolock,timeo=200 (code=exited, status=32)
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: media-jessa.mount mount process exited, code=exited status=32 Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: Failed to mount /media/jessa. Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: Unit media-jessa.mount entered failed state. Feb 22 08:52:55 andrea.zeeroos.de mount[1849]: mount.nfs: Failed to resolve server mavie.zeeroos.int: Name or service...known Hint: Some lines were ellipsized, use -l to show in full.
[root@andrea ~]# host mavie.zeeroos.int mavie.zeeroos.int has address 192.168.17.124 mavie.zeeroos.int has IPv6 address 2001:6f8:11d5:0:215:17ff:fe36:aa4e
On 02/22/2015 09:00 AM, Jens Neu wrote:
Dear list,
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are no longer mounted at boot. Claims that the nfs server is not resolvable, but it clearly is. Raised the timeo to 200, but no luck. Hints? Bugworthy?
regards Jens
forgot to add, mount -a after system is running works just fine:
[root@andrea ~]# mount -a
[root@andrea ~]# mount | grep julie mavie.zeeroos.int:/media/julie-raid on /media/julie-raid type nfs (rw,nodev,noatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=tcp,timeo=200,retrans=2,sec=sys,mountaddr=192.168.17.124,mountvers=3,mountport=59740,mountproto=tcp,local_lock=all,addr=192.168.17.124,_netdev)
-Jens
On 02/22/15 16:06, Jens Neu wrote:
On 02/22/2015 09:00 AM, Jens Neu wrote:
Dear list,
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are no longer mounted at boot. Claims that the nfs server is not resolvable, but it clearly is. Raised the timeo to 200, but no luck. Hints? Bugworthy?
regards Jens
forgot to add, mount -a after system is running works just fine:
[root@andrea ~]# mount -a
[root@andrea ~]# mount | grep julie mavie.zeeroos.int:/media/julie-raid on /media/julie-raid type nfs (rw,nodev,noatime,vers=3,rsize=8192,wsize=8192,namlen=255,hard,nolock,proto=tcp,timeo=200,retrans=2,sec=sys,mountaddr=192.168.17.124,mountvers=3,mountport=59740,mountproto=tcp,local_lock=all,addr=192.168.17.124,_netdev)
-Jens
Are you using the DNS server of the nfs client system?
On 02/22/15 17:40, Jens Neu wrote:
On 02/22/2015 09:13 AM, Ed Greshko wrote:
Are you using the DNS server of the nfs client system?
All my systems use 192.168.17.2 as dns server: nfs-server, client(s), etc. Technically the dns server is a CentOS 6.6 KVM machine with bind9 on the nfs-server.
I only see this this issue when my nfs client is running as my DNS server and the resolv.conf points to "nameserver 127.0.0.1".
My guess is a race condition with network and DNS server startup and I even filed a bugzilla on it a while back. I used a workaround via rc.local. I've not continued to track the bugzilla since my network configuration has changed since then.
On Sun, 22 Feb 2015 09:00:32 +0100 Jens Neu wrote:
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are no longer mounted at boot.
My consistent experience is that systemd has no clue when the network is "up" if by up you mean actually capable of talking to other things on the network. Thus all of the dependencies it waits on never wait long enough. I moved a slew of things to rc.local to have them restarted with different delays between them and also run a script there which keeps trying to mount all my NFS shares in a background loop till they actually mount. Only with enough junk in rc.local does my system boot reliably.
Yes. I have noted systemd stops the network then tries to umount nfs on fedora 20. Not really a good plan.
And I also did the rc.local mount as it was not mounting on boot because it tries to mount nfs before the network is live and fails.
There do seem to be some significant issues around nfs and network start/stop timing.
On Sun, Feb 22, 2015 at 8:14 AM, Tom Horsley horsley1953@gmail.com wrote:
On Sun, 22 Feb 2015 09:00:32 +0100 Jens Neu wrote:
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are no longer mounted at boot.
My consistent experience is that systemd has no clue when the network is "up" if by up you mean actually capable of talking to other things on the network. Thus all of the dependencies it waits on never wait long enough. I moved a slew of things to rc.local to have them restarted with different delays between them and also run a script there which keeps trying to mount all my NFS shares in a background loop till they actually mount. Only with enough junk in rc.local does my system boot reliably. -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
On 02/22/2015 03:24 PM, Roger Heflin wrote:
Yes. I have noted systemd stops the network then tries to umount nfs on fedora 20. Not really a good plan.
Did you try f21?
I share your experience on f20, but the effect "healed by itself" with f21. Actually, this really annoying deficiency of f20 was the #1 reason for me to switch to f21.
Ralf
On 02/22/2015 06:50 PM, Ralf Corsepius wrote:
I share your experience on f20, but the effect "healed by itself" with f21. Actually, this really annoying deficiency of f20 was the #1 reason for me to switch to f21.
Unfortunately - whatever this problem is - it does not "heal itself" with 21, since my system is on 21 with patches up to yesterday.
-Jens
On Sun, 2015-02-22 at 09:14 -0500, Tom Horsley wrote:
My consistent experience is that systemd has no clue when the network is "up" if by up you mean actually capable of talking to other things on the network. Thus all of the dependencies it waits on never wait long enough.
There was a thread about that, last year, I think. Another target was added to solve that stupid dependency. I can't remember what it was called, but it meant "actually on-line," as opposed to "somewhere there is some aspect of a network."
Tom Horsley:
My consistent experience is that systemd has no clue when the network is "up" if by up you mean actually capable of talking to other things on the network. Thus all of the dependencies it waits on never wait long enough.
Tim:
There was a thread about that, last year, I think. Another target was added to solve that stupid dependency. I can't remember what it was called, but it meant "actually on-line," as opposed to "somewhere there is some aspect of a network."
Realising that I didn't really finish saying what I meant before sending, earlier on... As I recall, the extra target was wedged in so that it has to be true, before it lets the other target become true (the one that all your applications are looking at to see whether you're on-line, or not).
But I still can't recall what /that/ thread actually was, to refer you to it, though.
On Feb 22, 2015 1:01 AM, "Jens Neu" jens@zeeroos.de wrote:
Dear list,
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are
no longer mounted at boot. Claims that the nfs server is not resolvable, but it clearly is. Raised the timeo to 200, but no luck. Hints? Bugworthy?
regards Jens
[root@andrea ~]# systemctl status media-jessa.mount ● media-jessa.mount - /media/jessa Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Sun 2015-02-22 08:52:55 CET;
1min 15s ago
Where: /media/jessa What: mavie.zeeroos.int:/media/jessa Docs: man:fstab(5) man:systemd-fstab-generator(8)Process: 1849 ExecMount=/bin/mount -n mavie.zeeroos.int:/media/jessa
/media/jessa -t nfs -o _netdev,rw,hard,intr,nfsvers=3,tcp,noatime,nodev,async,rsize=8192,wsize=8192,vers=3,nolock,timeo=200 (code=exited, status=32)
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: media-jessa.mount mount
process exited, code=exited status=32
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: Failed to mount
/media/jessa.
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: Unit media-jessa.mount
entered failed state.
Feb 22 08:52:55 andrea.zeeroos.de mount[1849]: mount.nfs: Failed to
resolve server mavie.zeeroos.int: Name or service...known
Hint: Some lines were ellipsized, use -l to show in full.
[root@andrea ~]# host mavie.zeeroos.int mavie.zeeroos.int has address 192.168.17.124 mavie.zeeroos.int has IPv6 address 2001:6f8:11d5:0:215:17ff:fe36:aa4e
--
I use a the systemd automount functionality to mount NFS shares on demand. Use "x-systemd.automount" as one of the mount options and the problem will go away. Bonus, if the network is legitimately down, it doesn't hold up booting.
`man systemd.mount` explains, http://www.freedesktop.org/software/systemd/man/systemd.mount.html .
--Pete
This poroblem occurs on other unices as well, try using the bg option in your nfs fstab entry. Andy On Sunday 22 February 2015 21:39:13 Pete Travis wrote:
On Feb 22, 2015 1:01 AM, "Jens Neu" jens@zeeroos.de wrote:
Dear list,
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are
no longer mounted at boot. Claims that the nfs server is not resolvable, but it clearly is. Raised the timeo to 200, but no luck. Hints? Bugworthy?
regards Jens
[root@andrea ~]# systemctl status media-jessa.mount ● media-jessa.mount - /media/jessa
Loaded: loaded (/etc/fstab) Active: failed (Result: exit-code) since Sun 2015-02-22 08:52:55 CET;
1min 15s ago
Where: /media/jessa What: mavie.zeeroos.int:/media/jessa Docs: man:fstab(5) man:systemd-fstab-generator(8)Process: 1849 ExecMount=/bin/mount -n mavie.zeeroos.int:/media/jessa
/media/jessa -t nfs -o _netdev,rw,hard,intr,nfsvers=3,tcp,noatime,nodev,async,rsize=8192,wsize=8192 ,vers=3,nolock,timeo=200 (code=exited, status=32)
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: media-jessa.mount mount
process exited, code=exited status=32
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: Failed to mount
/media/jessa.
Feb 22 08:52:55 andrea.zeeroos.de systemd[1]: Unit media-jessa.mount
entered failed state.
Feb 22 08:52:55 andrea.zeeroos.de mount[1849]: mount.nfs: Failed to
resolve server mavie.zeeroos.int: Name or service...known
Hint: Some lines were ellipsized, use -l to show in full.
[root@andrea ~]# host mavie.zeeroos.int mavie.zeeroos.int has address 192.168.17.124 mavie.zeeroos.int has IPv6 address 2001:6f8:11d5:0:215:17ff:fe36:aa4e
--
I use a the systemd automount functionality to mount NFS shares on demand. Use "x-systemd.automount" as one of the mount options and the problem will go away. Bonus, if the network is legitimately down, it doesn't hold up booting.
`man systemd.mount` explains, http://www.freedesktop.org/software/systemd/man/systemd.mount.html .
--Pete
On Mon, 2015-02-23 at 09:17 +0000, Andrew R Paterson wrote:
This poroblem occurs on other unices as well, try using the bg option in your nfs fstab entry.
Putting fstab entries in is really only useful for what I consider to be permanently available shares (or drives, if we're not talking about nfs). i.e. Things that are *always* present.
For anything that is transitory (flash drives, plug in hard drives), it's not the best way to handle it, it can cause seriously annoying problems. Such things may not always be connected, might be swapped for other drives plugged in the same place (a device name is not unique), may not always have the same volume name (several different drives), or may not have unique names (flashdrives or volume groups with common default volume names). Likewise with things on a network, which might not always be booted up, or the times that the remote things and your computer are booted up are not always the same. You end up with a mass of crap in your fstab file, that you have to manage by hand.
You really want something doing auto-mounting, whether that's noticing that a drive has been plugged into a port, a device with storage (such as a phone) has been plugged in or has joined the network, et cetera, that finds its appearance, and makes it available for you. And that's how I've used CD and DVD data discs, flash drives, USB hard drives, digital cameras, for years. Plug it in, drive appears, use it. This is how people expect it to work.
Or, something that finds it when you look for it, such as how autofs works. You browse your way over to /net/hostname/sharename and it appears. I've done that, for many years, with NFS, and has been a godsend over fstab entries (where you get hideously stalled boot-ups, or stalled shutdowns, because something wasn't available at the right time, and backgrounding it really didn't help).
And this (autofs) is /almost/ how I expect it to work. The fly in that ointment has been that you have to hand type in the hostname, the first time around, because they don't appear in the list simply because they're available. You have to look for them. But once done, it remains for the session, and you can bookmark filepaths so you don't have to type it in again, next time (just use the bookmarked shortcut).
A second fly in that ointment has been that I haven't been able to get a Fedora 20 box to share one of its filepaths out, at all. No amount of messing with the firewall or SELinux has born fruit.
On 02/23/2015 05:18 PM, Tim wrote:
On Mon, 2015-02-23 at 09:17 +0000, Andrew R Paterson wrote:
This poroblem occurs on other unices as well, try using the bg option in your nfs fstab entry.
Putting fstab entries in is really only useful for what I consider to be permanently available shares (or drives, if we're not talking about nfs). i.e. Things that are *always* present.
I consider these shares to be "always present" and the host won't function properly without them. So I don't want to mess with automount stuff. -Jens
On 02/25/15 17:48, Jens Neu wrote:
On 02/23/2015 05:18 PM, Tim wrote:
On Mon, 2015-02-23 at 09:17 +0000, Andrew R Paterson wrote:
This poroblem occurs on other unices as well, try using the bg option in your nfs fstab entry.
Putting fstab entries in is really only useful for what I consider to be permanently available shares (or drives, if we're not talking about nfs). i.e. Things that are *always* present.
I consider these shares to be "always present" and the host won't function properly without them. So I don't want to mess with automount stuff.
FWIW, did you try just using the IP address?
Tim:
Putting fstab entries in is really only useful for what I consider to be permanently available shares (or drives, if we're not talking about nfs). i.e. Things that are *always* present.
Jens Neu wrote:
I consider these shares to be "always present" and the host won't function properly without them. So I don't want to mess with automount stuff.
Did you look into the thing I mentioned earlier on? Inserting a new target into systemd so that the network-is-online type of target only says its on-line when it really is actually on-line.
Maybe forcing the system to wait until network is really working might help your problem.
On Wed, Feb 25, 2015 at 4:45 AM, Jens Neu jens@zeeroos.de wrote:
On 02/23/2015 10:17 AM, Andrew R Paterson wrote:
This poroblem occurs on other unices as well, try using the bg option in your nfs fstab entry.
unfortunatley option bg does not resolve it. mount -a still is the way to go.
Pre-systemd there was a "_netdev" option for network mounts. It should still work.
You can also create a .mount systemd unit.
For example:
# cat /etc/systemd/system/mnt-fedora.mount [Unit] After=network-online.target [Mount] What=127.0.0.1:/srv Where=/mnt/fedora Type=nfs Options=nfsvers=4
# sc status mnt-fedora.mount ● mnt-fedora.mount - /mnt/fedora Loaded: loaded (/etc/systemd/system/mnt-fedora.mount; static; vendor preset: enabled) Active: active (mounted) since Wed 2015-02-25 05:51:12 EST; 6s ago Where: /mnt/fedora What: 127.0.0.1:/srv Process: 4491 ExecMount=/bin/mount 127.0.0.1:/srv /mnt/fedora -n -t nfs -o nfsvers=4 (code=exited, status=0/SUCCESS)
Feb 25 05:51:12 yoga.lenovo systemd[1]: Mounting /mnt/fedora... Feb 25 05:51:12 yoga.lenovo systemd[1]: Mounted /mnt/fedora.
On Wed, Feb 25, 2015 at 5:55 AM, Tom H tomh0665@gmail.com wrote:
On Wed, Feb 25, 2015 at 4:45 AM, Jens Neu jens@zeeroos.de wrote:
On 02/23/2015 10:17 AM, Andrew R Paterson wrote:
This poroblem occurs on other unices as well, try using the bg option in your nfs fstab entry.
unfortunatley option bg does not resolve it. mount -a still is the way to go.
Pre-systemd there was a "_netdev" option for network mounts. It should still work.
You can also create a .mount systemd unit.
For example:
# cat /etc/systemd/system/mnt-fedora.mount [Unit] After=network-online.target [Mount] What=127.0.0.1:/srv Where=/mnt/fedora Type=nfs Options=nfsvers=4
# sc status mnt-fedora.mount ● mnt-fedora.mount - /mnt/fedora Loaded: loaded (/etc/systemd/system/mnt-fedora.mount; static; vendor preset: enabled) Active: active (mounted) since Wed 2015-02-25 05:51:12 EST; 6s ago Where: /mnt/fedora What: 127.0.0.1:/srv Process: 4491 ExecMount=/bin/mount 127.0.0.1:/srv /mnt/fedora -n -t nfs -o nfsvers=4 (code=exited, status=0/SUCCESS)
Feb 25 05:51:12 yoga.lenovo systemd[1]: Mounting /mnt/fedora... Feb 25 05:51:12 yoga.lenovo systemd[1]: Mounted /mnt/fedora.
Don't forget to comment out the nfs fstab entry.
On 02/22/2015 09:00 AM, Jens Neu wrote:
Dear list,
maybe since 2 weeks (close to upgrade to Twenty_One), my nfs shares are no longer mounted at boot. Claims that the nfs server is not resolvable, but it clearly is. Raised the timeo to 200, but no luck. Hints? Bugworthy?
Dear all,
iIssue is resolved, turns out it was a faulty cable. The connection sometimes toggled between 100Base-T and 1000Base-T (with happy errors), and this obviously makes systemd stop mounting the nfs drives. Turns out, mount -a on running system took a long time (10s for 4 shares, <1s is normal) but worked nevertheless.
regards Jens
-
Andy Paterson -
Ed Greshko -
Jens Neu -
Pete Travis -
Ralf Corsepius -
Roger Heflin -
Tim -
Tom H -
Tom Horsley