Description of problem: With F14, nfs-mounts in fstab didn't block anything. I didn't have to worry about them, they were there in my homenetwork, or else they weren't. They would try to mount in background but eventually fail, all without me noticing. Perfect. Now I want to replicate that behaviour with systemd: I have this mountpoint in /etc/fstab 192.168.2.250:/mnt/storage /home/jan/server nfs noauto,comment=systemd.automount 0 0 and it works fine when I'm in my homenetwork. However it doesn't when I'm not. I can't run 'll ~/' because it tries to mount the nfs stuff and sits there waiting. Also it still shows as mounted when suspending in my homenetwork and resuming somewhere else. Then I can't even ctrl-c the 'll ~/' anymore. It would be cool to have the same behaviour as in F14 again. Version-Release number of selected component (if applicable): systemd-26-1.fc15 How reproducible: always Steps to Reproduce: 1. create nfs-mountpoint in /etc/fstab with noauto,comment=systemd.automount 2. make the nfs-server unavailable (or switch networks) 3. run for example 'll ~/' in the directory containing the mountpoint Actual results: blocking, sits there and nothing happening Expected results: at least timeout, much better would be returning immediately though (like in F14). Additional info:
... If you don't want it to attempt to automount, remove 'comment=systemd.automount'. Am I missing something here?
I want it to automount when I'm in my home network. I don't want it to block fs access when I'm in another network. That was the previous behaviour, it was really comfortable.
Jan, maybe you can play with the nfs options to set a timeout and get it to try a background mount? Set your fstab entry to include 'bg,timeo=xxx,...' See 'man nfs' for details.
(In reply to comment #2) > I want it to automount when I'm in my home network. I don't want it to block fs > access when I'm in another network. That was the previous behaviour, it was > really comfortable. By "previous behaviour" you mean the behaviour in F14 with using the autofs service? Does the same autofs configuration still work in F15 for you (i.e. without using systemd's automount feature)? (Just trying to determine the severity of the bug.)
(In reply to comment #4) > By "previous behaviour" you mean the behaviour in F14 with using the autofs > service? I guess. I just added an nfs-entry to /etc/fstab > Does the same autofs configuration still work in F15 for you (i.e. without > using systemd's automount feature)? > (Just trying to determine the severity of the bug.) No, it doesn't work. The same line blocks my boot (timeout) when the NFS-server is not available.
(In reply to comment #3) > Jan, maybe you can play with the nfs options to set a timeout and get it to try > a background mount? Set your fstab entry to include 'bg,timeo=xxx,...' See > 'man nfs' for details. yup, 'defaults,bg,timeo=10' seems to work. I now have two /sbin/mount.nfs-processes running though. They don't seem to get terminated. With F14 they were ran from a NM dispatcher-script afaik, and terminated after a while.
and the log-file is spammed: Jun 16 14:44:29 jan mount[829]: mount to NFS server '192.168.2.250' failed: No route to host, retrying Jun 16 14:46:26 jan mount[1018]: mount to NFS server '192.168.2.250' failed: No route to host, retrying [...]
I tried with native .mount/.automount-units but to no avail. Since the nfs-folder is in ~/, gnome-shell won't even finish starting (no timeout). [jan@jan system]$ cat home-jan-server.mount [Mount] What=192.168.2.250:/mnt/storage Where=/home/jan/server Type=nfs Options=bg TimeoutSec=20 KillMode=control-group [jan@jan system]$ cat home-jan-server.automount [Automount] Where=/home/jan/server [Install] WantedBy=remote-fs.target $ sudo systemctl daemon-reload && sudo systemctl enable home-jan-server.automount
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
This bug is a really a pain in the arse... In my home network I have a NFS share with various media files that are mounted at /stuff/. This is not available whenever I am in any other network than home. Also, the network is not available until the boot process has been completed, I've logged in, and connected to the wireless network. Therefore, no NFS shares can be mounted during boot, regardless of if I'm at home or not. In Fedora 13, 192.168.1.2:/stuff /stuff nfs defaults 0 0 did *exactly* what I wanted. It didn't block the boot, and whenever I connected to a network, /etc/NetworkManager/dispatcher.d/05-netfs was triggered, and if I happened to be at home, the NFS share was successfully. If I wasn't at home, the dispatcher.d script failed to mount the share, of course, however this wasn't a problem, as the timeout/failure happened entirely in the background and did not at any point prevent me from actually using my computer whatsoever. In F15, on the other hand, the above fstab line causes a excruciatingly long boot delay, because it attempts to mount the share (which obviously won't work since there's no network connectivity), and refuses to show the display manager login screen until the mount attempt has failed. Adding the "bg" parameter has no effect. The comment="systemd.automount" solution isn't quite what I want either, as it causes "ls /" to hang - at least when I'm not in my home network. In F13, this was no problem. "ls /stuff" when not at home just showed an empty directory, which is much much better than a hang. Is there any way I can replicate the F13 behaviour, short of writing my own NetworkManager dispatcher.d script that explicitly attempts to mount my NFS share when the network is activated, while at the same time removing the fstab line completely? Tore
(In reply to comment #10) > ... and refuses to show the display manager login screen until > the mount attempt has failed. What if you add the "nofail" mount option? That will tell systemd not to add an ordering dependency between the mount and remote-fs.target.
(In reply to comment #11) > What if you add the "nofail" mount option? That will tell systemd not to add an > ordering dependency between the mount and remote-fs.target. It helps a bit, with "nofail" the bootup process doesn't block waiting for the mount attempt to time out any more. However, it makes the mount attempt by the NetworkManager fail as well, presumably because (if I log in as soon as the login screen appears) the mount process spawned by systemd is still running in the background and is blocking the NetworkManager-spawned one from performing the mount. If I wait a bit in order for the systemd mount to time out in the background, and then connect to the network, then the share gets mounted properly. Is it possible to make systemd ignore the fstab line completely? (In a way that won't make NetworkManager ignore it as well, that is.) Tore
Is this still a problem or can this bug be closed?
Afaik there is no way to have systemd ignore /etc/fstab completly and I seriously doubt that that option will be added. Anyway closing this bug if this still is an issue please reopen this bug and enable the relevant services on startup and boot with 'log_buf_len=1M systemd.log_level=debug systemd.log_target=kmsg' then save the output of the dmesg command and attach it here. Thanks
(In reply to comment #14) > Afaik there is no way to have systemd ignore /etc/fstab completly and I > seriously doubt that that option will be added. Actually, disabling remote-fs.target could have the desired effect.