nfsd.service: Fix startup gap #400
Conversation
We've seen that a client sometimes gets EPERM when a server reboots. This is caused by `exportfs -ra` running during boot when the network is not yet available and the hostnames can't be resolved. Start nfsd after the network is online. Also make sure, that mxmounts is done. Also, don't unexport on nfsd exit. exportfs(8): Exporting to IP networks or DNS and NIS domains does not enable clients from these groups to access NFS immediately. Rather, these sorts of exports are hints to rpc.mountd(8) to grant any mount requests from these clients. This is usually not a problem, because any existing mounts are preserved in rmtab across reboots.
|
Tested on claptrap (client) and dose (server). "Permission denied" during reboot was reproducible and is gone after this change. |
| @@ -12,7 +15,7 @@ ExecStart=/usr/sbin/rpc.mountd --foreground --manage-gids | |||
| ExecStartPost=/usr/sbin/rpc.nfsd --lease-time 90 --grace-time 90 --no-nfs-version 3 8 | |||
| ExecStartPost=bash -c "(sleep 10;exportfs -r;sleep 20;exportfs -r;sleep 30;exportfs -r)&" | |||
| ExecReload=/usr/sbin/exportfs -ra | |||
| ExecStopPost=/usr/sbin/rpc.nfsd 0 ; /usr/sbin/exportfs -ua | |||
| ExecStopPost=/usr/sbin/rpc.nfsd 0 | |||
There was a problem hiding this comment.
The upstream systemd unit has:
22 [Service]
23 Type=oneshot
24 RemainAfterExit=yes
25 ExecStartPre=-/usr/sbin/exportfs -r
26 ExecStart=/usr/sbin/rpc.nfsd
27 ExecStop=/usr/sbin/rpc.nfsd 0
28 ExecStopPost=/usr/sbin/exportfs -au
29 ExecStopPost=/usr/sbin/exportfs -f
30
31 ExecReload=-/usr/sbin/exportfs -r
There was a problem hiding this comment.
I'm not sure, why exportfs -u is in there.
There was a problem hiding this comment.
Sorry can you elaborate on the relationship of not unexporting and manual page quote?
Unexporting Directories
The third synopsis shows how to unexport a currently exported directory. When using exportfs ‐ua, all entries listed in
/var/lib/nfs/etabare removed from the kernel export tables, and the file is cleared. This effectively shuts down all NFS activity.[…]
When unexporting a network or domain entry, any current exports to members of this group will be checked against the remaining valid exports and if they themselves are no longer valid they will be removed.
Isn’t This effectively shuts down all NFS activity. what we want?
|
Obsoleted by #433 |
We've seen that a client sometimes gets EPERM when a server reboots.
This is caused by
exportfs -rarunning during boot when the network is not yet available and the hostnames can't be resolved. Start nfsd after the network is online.Also make sure, that mxmounts is done.
Also, don't unexport on nfsd exit.
exportfs(8):
Exporting to IP networks or DNS and NIS domains does not enable
clients from these groups to access NFS immediately. Rather,
these sorts of exports are hints to rpc.mountd(8) to grant any mount
requests from these clients. This is usually not a problem, because
any existing mounts are preserved in rmtab across reboots.