(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
On 06/27/2015 03:39 PM, Jonas Meurer wrote:
> Sure. My /etc/network/interfaces is pretty simple:
>
>> # This file describes the network interfaces available on your system
>> # and how to activate them. For more information, see interfaces(5).
>>
> # The loopback network interface
> auto lo
> iface lo inet loopback
>
> # The primary network interface
> #allow-hotplug eth0
> auto eth0
> iface eth0 inet static
> address 172.18.10.34
> netmask 255.255.255.0
> network 172.18.10.0
> broadcast 172.18.10.255
> gateway 172.18.10.1
> # dns-* options are implemented by the resolvconf package, if installed
> dns-nameservers XXX.XXX.XXX.XXX XXX.XXX.XXX.XXX
That looks fine, there shouldn't be any problems with that.
>> Could you run the following?
>>
>> systemd-analyze plot > bootup.svg
>>
>> This will produce an SVG file that tells you when and in which order
>> systemd started different units at boot. Could you attach that file?
>> It may be able to tell us what happened.
>
> Didn't know about that feature until know. Happy to learn new things
> about systemd every day :) So ... here we go. The SVG is attached. If I
> understand the output, then my NFS share etc-exim4-virtual.mount is
> started just before rpcbind.service and network-online.target, right?
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
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.
Mounting it later it will work because rpc.gssd has been started by
that point.
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.
> So maybe you were correct earlier in this thread, that rpcbind is
> started to late? Is there an easy solution to fix it? Maybe by adding
> rpcbind to the LSB header 'Required-Start' of nfs-common init script?
> I just tried that, unfortunately it didn't help at all.
You were on the right track here, but it's not rpcbind itself that's
the issue. (See above.)
For the bugtracker: there has to be a new ordering dependency
between remote-fs-pre.target and nfs-common.service. Ideally, since
this is NFS-specific, this should probably go in the nfs-common
package, but since at least in Jessie nfs-common is an init script
and not a systemd service file, it might be better to explicitly add
the After= dependency in the systemd package - whereas for Stretch
there probably will be a native systemd unit file, so that's where
the Before=remote-fs-pre.target dependency could be added. (IMHO.)
Christian
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=775542
Attachment:
signature.asc
Description: OpenPGP digital signature