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 -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/558ee51e.4040...@freesources.org
