Hi, On 07/16/2015 09:04 AM, n n wrote: > trying to mount nfs-shares at boot I have exactly the problem mentioned by > Christian: > (in Message-id: <558e8105.5030...@iwakd.de>) > >> - On some systems with static IP addresses (and >> /etc/network/interfaces), I had the problem that even though the >> interface was conisdered up and ready by the kernel, the switch it >> was connected to needed 30s or so to realize that fully (and >> packets were simply dropped beforehand). Since those systems also >> needed to mount NFS... > > Christian then recommends applying a unit he calls wait-for-nfs-server. > > My problem now is that if I apply that unit (or do other tricks like a sleep > in > /etc/network/interfaces the mounts are there after booting, but I have errors > like that in journalctl: > > Jul 14 16:07:02 hhh rpcbind[657]: Starting rpcbind daemon.... > Jul 14 16:07:02 hhh rpc.statd[681]: Version 1.2.8 starting > Jul 14 16:07:02 hhh rpc.statd[681]: Flags: TI-RPC > Jul 14 16:07:02 hhh rpc.statd[682]: Version 1.2.8 starting > Jul 14 16:07:02 hhh rpc.statd[682]: Flags: TI-RPC > Jul 14 16:07:02 hhh rpc.statd[683]: Version 1.2.8 starting > Jul 14 16:07:02 hhh sm-notify[684]: Version 1.2.8 starting > [...] > So, rpc.statd is there, but why with the --no-notify option? > > To me it looks like rpc.statd gets started multiple times (why?) and > that confuses me and the whole nfs mount process.
Ok, so in your case you're also running into the same bug [1] of this very same thread, namely that remote filesystems are not ordered relative to nfs-common. In your case it's rpc.statd and not rpc.gssd, but the cause is the same. In your case, instead of mounts just failing, the mount.nfs binary has a weird logic in it that for NFSv2 and NFSv3 mounts, if statd isn't already running, it will call /usr/sbin/start-statd. That's a script (you can look at it) and it will start rpc.statd multiple times - with the --no-notify option. (Because statd notifications should only happen at boot, but mount.nfs isn't just called at boot.) The problem you have here is the following: - nfs-common tries to start statd regularly (without any options unless you specified them explicitly via /etc/default/nfs-common) - at the same time you apparently have multiple (!) nfs mounts for which mount.nfs is started - each of those mount.nfs processes tries to run statd with the --no-notify option - then they start getting it each other's way, at the end one wins all or all but one mounts (depending on which wins) will just fail The start-statd logic of mount.nfs is something that doesn't jibe well with systemd, since it was designed back when nfs mounts were not done in parallel but rather one after the other, so that even if it were executed at boot, it wouldn't have caused this issue, because boot was much more serialized. (Also, starting statd in systemd as part of a mount unit is not a good idea.) To solve your problem: Just apply the same workaround until it's fixed in Jessie: make sure that NFS mounts only happen after nfs-common is done, then mount.nfs will not try to start statd itself (because it's already running) and boot should work out. For this, create a directory /etc/systemd/system/nfs-common.service.d and then create a file /etc/systemd/system/nfs-common.service.d/remote-fs-pre.conf with the following contents: [Unit] Before=remote-fs-pre.target Then it should work. Regards, Christian [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775542
signature.asc
Description: OpenPGP digital signature
