Re: auto-mount NFS shares on boot

[Jonas Meurer <jonas@freesources.org>]

Hi Christian,

Am 27.06.2015 um 16:07 schrieb Christian Seiler:
> (Ccing the bugtracker because it appears you've stumbled upon a bug
> that also a few other people had, see below. Please don't reply to the
> bugtracker yourself unless you feel it's relevant for the bug report.)
> 
> Link to thread on debian-user for people reading the bug report:
> https://lists.debian.org/debian-user/2015/06/msg01508.html

Thanks for linking this thread to bugreport #775542. I wasn't aware of
that bugreport yet.

> On 06/27/2015 03:39 PM, Jonas Meurer wrote:
>>> Could you run the following?
>>> systemd-analyze plot > bootup.svg
> 
> Ok, so the following is going on:
> 
>   - local-fs.target is reached, this leads to networking.service
>     being started
> 
>   - networking.service sets up network configuration (takes 172ms)
> 
>   - after networking.service is done, network.target is reached
> 
>   - after network.target is reached, network-online.target is
>     reached (since you don't have any services that wait for the
>     network connection like NetworkManager-wait-online.service,
>     but you also don't need it here, since networking.service
>     with a static configuration and 'auto eth0' will make sure
>     the network is up properly before even network.target is
>     reached, so that's not a problem)
> 
>   - but then immediately after that systemd tries to mount the NFS
>     filesystem
> 
>   - in parallel, first rpcbind and then nfs-common is started

Thanks a lot for disassembling and explaining the boot procedure. I see
that the problem here is that systemd doesn't wait for rpcbind.service
and nfs-common.service to finish before it mounts the NFS shares.

> This is a bug, that shouldn't happen. Rationale:
> 
> The problem here is that you are using sec=krb5i type mounts, where
> rpc.gssd needs to have been started (by nfs-common) BEFORE mounting
> can take place. Unfortunately, there's no ordering relating
> nfs-common to remote filesystems, so systemd will start them in
> parallel and the mount will fail.
> 
> I myself have never seen this because I've only used sec=sys NFSv4
> mounts with Jessie, and those don't require any service to be started
> when trying to mount them - and while the idmapper may be required to
> have proper permissions, that can be started later (or not at all if
> you use the new nfsidmap + request-key logic instead of idmapd).
> 
> But with sec=krb5i mounts, this is bad, because you need rpc.gssd to
> mount the filesystems.
> 
> What's missing here is an ordering dependency between
> remote-fs-pre.target and nfs-common.service.
> 
> Searching through the bugtracker, this appears to be the same bug
> as #775542 [1], that's why I've copied this message to that bug
> report.
> 
> Could you try to do the following:
> 
> 1. create a directory /etc/systemd/system/remote-fs-pre.target.d
> 2. create a file /etc/systemd/system/remote-fs-pre.target.d/nfs.conf
>    with the following contents:
> 
> [Unit]
> After=nfs-common.service
> 
> And then reboot your system? I would bet it should work then.

Perfect, that solution works like a charm. nfs-common is started before
remote-fs, thus rpc.gssd runs already when the NFS share is mounted.

I suggest to add this simple fix to Jessie by uploading it to
stable-proposed-updates. What do you think? Also, do you think that
/etc/systemd/system/remote-fs-pre.target.d/nfs.conf belongs to systemd
package or to nfs-common? I would say it belongs to nfs-common as that
one provides the required tools and services to mount NFS shares on a
client.

What do the maintainers think? I'm happy to prepare a patch for either
package and eventually make an upload to stable-proposed-updates if the
maintainers don't have time to do so themselves. Just tell me if I
should go ahead.

Cheers,
 jonas