nfs no longer mounted at boot with systemd

Bug #1429975 reported by Marc Deslauriers on 2015-03-09
24
This bug affects 5 people
Affects Status Importance Assigned to Milestone
systemd (Ubuntu)
High
Martin Pitt

Bug Description

I updated my vivid laptop today, and now boot with systemd by default.
Unfortunately, my nfs mount no longer mounts at boot.

From syslog:

Mar 9 14:38:20 mdlinux mount[866]: mount.nfs: Network is unreachable
Mar 9 14:38:20 mdlinux systemd[1]: mnt-server.mount mount process exited, code=exited status=32
Mar 9 14:38:20 mdlinux systemd[1]: Failed to mount /mnt/server.
Mar 9 14:38:20 mdlinux systemd[1]: Dependency failed for Remote File Systems.
Mar 9 14:38:20 mdlinux systemd[1]: Job remote-fs.target/start failed with result 'dependency'.
Mar 9 14:38:20 mdlinux systemd[1]: Unit mnt-server.mount entered failed state.

This is happening before my network interfaces are ready:

Mar 9 14:38:21 mdlinux NetworkManager[820]: <info> (eth0): preparing device

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: nfs-common 1:1.2.8-9ubuntu6
ProcVersionSignature: Ubuntu 3.19.0-7.7-generic 3.19.0
Uname: Linux 3.19.0-7-generic x86_64
ApportVersion: 2.16.2-0ubuntu2
Architecture: amd64
CurrentDesktop: Unity
Date: Mon Mar 9 14:45:48 2015
InstallationDate: Installed on 2013-11-26 (467 days ago)
InstallationMedia: Ubuntu 13.10 "Saucy Salamander" - Release amd64 (20131016.1)
SourcePackage: nfs-utils
UpgradeStatus: Upgraded to vivid on 2015-03-07 (2 days ago)

Marc Deslauriers (mdeslaur) wrote :
Steve Langasek (vorlon) wrote :

I've seen this as well on my desktop. For me it was not a regression vs. upstart (there are bug reports about nfs mounts similarly not being mounted at boot under upstart in Ubuntu 14.10 and later), which is why I did not consider this a blocker for switching by default.

Looking at the systemd mount generator output on my system, I see entries such as:
$ cat /run/systemd/generator/srv.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=remote-fs.target

[Mount]
What=<server>:/
Where=/srv
Type=nfs4
Options=soft,intr,async,nolock,sec=krb5i,proto=tcp
$

This is notably lacking any dependency information requiring the network to be up before trying (and failing) to start the unit.

Reassigning to systemd.

affects: nfs-utils (Ubuntu) → systemd (Ubuntu)
Changed in systemd (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
Martin Pitt (pitti) wrote :

Indeed, these should have a Wants=/After=network-online.target.

tags: added: systemd-boot
Changed in systemd (Ubuntu):
importance: Undecided → High
status: New → In Progress
Martin Pitt (pitti) wrote :

Asked on upstream ML: http://lists.freedesktop.org/archives/systemd-devel/2015-March/029226.html

In the meantime, you could edit /lib/systemd/system/remote-fs-pre.target to append

Wants=network-online.target
After=network-online.target

This should fix the boot, at least if you use ifupdown (which I assume if you use NFS). With network-manager it won't work yet as we haven't enabled NetworkManager-wait-online.service yet, see bug 1430280).

Marc Deslauriers (mdeslaur) wrote :

I have always used network-manager, so I'll wait.

Marc Deslauriers (mdeslaur) wrote :

In case this is helpful:

$ cat /run/systemd/generator/mnt-server.mount
# Automatically generated by systemd-fstab-generator

[Unit]
SourcePath=/etc/fstab
Documentation=man:fstab(5) man:systemd-fstab-generator(8)
Before=remote-fs.target

[Mount]
What=192.x.x.x:/opt/share
Where=/mnt/server
Type=nfs
Options=rw,rsize=8192,wsize=8192,hard,intr

$ grep nfs /etc/fstab
192.x.x.x:/opt/share /mnt/server nfs rw,rsize=8192,wsize=8192,hard,intr 0 0

Martin Pitt (pitti) wrote :

Discussion on the ML confirmed that these *do* wait (implicitly) on network-online.target. If you do "systemctl show -p Wants -p After mnt-server.mount" you should see

Wants=network-online.target system.slice
After=remote-fs-pre.target network-online.target network.target system.slice -.mount [...]

So this is merely a duplicate of bug 1430280.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers