Hi Christian,
thanks for the comprehensive reply. It helps a lot to better understand
the details of systemd NFS mount handling.
Am 27.06.2015 um 12:55 schrieb Christian Seiler:
> On 06/26/2015 07:44 PM, Arno Schuring wrote:
>>> On 2015-06-26 18:38 +0200, Jonas Meurer wrote:
>>> mount.nfs4 prints this not very enlightening message if the mount
>>> syscall fails with EINVAL.
>>
>> If I've understood the mount scripts correctly, the error is correct:
>> the _netdev mount option is for mount scripts only, and should /not/
>> be passed to the mount command.
>
> Not quite. mount(8) and mount.nfs4(8) do understand and ignore the
> _netdev option (at least in Jessie's version [1]), so they don't need
> to be filtered.
That's what I already assumed. Thanks for providing the links to confirm
this.
> Also:
>
> - _netdev is not required for nfs4/nfs filesystems, systemd has a
> whitelist of filesystems it implicitly considers network
> filesystems, and nfs4 is among them [2]
>
> Also, if systemd hadn't detected it to be a network filesystem, it
> would have assumed it to be a local filesystem - and for failing
> local filesystems systemd drops you in an emergency shell, so the
> systemd wouldn't even have booted then.
>
> _netdev does have its uses [3], but not for a typical NFS mount.
>
> - the same error also occurs in the original poster's message when
> _netdev was not specified, so it doesn't have to do anything with
> this option
Ok, so the bottom line is that I don't need the '_netdev' option for NFS
mounts at all. I removed it from my fstab.
>> I would guess that this is another case where systemd breaks
>> backwards compatibility. Maybe it's mentioned in the release notes?
>
> No, systemd is not at fault here. (See above.)
>
> With respect to the original problem:
>
> Q1. Does it mount manually after boot?
>
> What does mount /var/vmail say?
As already mentioned, mounting the filesystems manually after the boot
process finished works as expected. I can mount the share by starting
'systemctl start var-vmail.mount'. Afterwards the NFS share is mounted
and 'systemctl status var-vmail.mount' says:
# systemctl status var-vmail.mount
● var-vmail.mount - /var/vmail
Loaded: loaded (/etc/fstab)
Active: active (mounted) since Sat 2015-06-27 12:55:55 UTC; 1s ago
Where: /var/vmail
What: nfs-server:/vmail
Docs: man:fstab(5)
man:systemd-fstab-generator(8)
Process: 982 ExecMount=/bin/mount -n nfs-server:/vmail /var/vmail -t
nfs4 -o sec=krb5i (code=exited, status=0/SUCCESS)
So I'm pretty sure that NFS is setup correctly both on server and
client. My problem is about mounting the NFS share automatically during
the boot process.
> [From here on assuming that the manual mount works:]
>
> Q5. What kind of network configuration do you use? It may be the case
> that you didn't tell it to make systemd wait for it to be online
> before attempting to mount stuff.[4] Scenarios:
The NFS client in question is a Xen DomU/VM server system. It doesn't
have NetworkManager installed and I didn't configure anything
systemd-networkd specific. My ethernet devices are configured in
/etc/network/interfaces.
> - you are using /etc/network/interfaces and have allow-hotplug eth0
> (or whatever your interface is called) in there
>
> Unfortunately, /etc/network/interfaces is Debian-specific and they
> don't have a hook for allow-hotplug interfaces w.r.t. the
> network-online.target logic of systemd
Very interesting. Indeed, debian-installer by default adds network
devices as 'allow-hotplug' to /etc/network/interfaces.
> However, since you need the interface at boot anyway, you don't
> need allow-hotplug, you can just change it to auto, e.g.:
> allow-hotplug eth0 -> auto eth0 in /etc/network/interfaces
>
> Then /etc/init.d/networking (which is used to set up the
> interfaces in Debian from /etc/network/interfaces) will wait until
> the interface is up before continuing
I changed 'allow-hotplug eth0' to 'auto eth0' in /etc/network/interfaces
now. Unfortunately it didn't have any effect. Still the same error
message during boot process, still no mounted NFS shares after boot.
> - 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, on Jessie systems I use the following unit
> file to try to ping the NFS server before systemd should continue
> with NFS mounts:
I don't believe that this is a problem here. The NFS client is inside a
private network that is routed on the Xen server, so no need to wait for
a switch to detect an 'up' link.
I'm still pretty confident that systemd for some reason tries to mount
the NFS shares before the network connection is established. The boot
log to console shows the failed mount attempts of NFS shares immediately
after the rootfs has been mounted, and at least before nfs-common has
been started:
> [...]
> fsck from util-linux 2.25.2
> /dev/mapper/debian--vg-root: clean, 33137/610800 files, 465651/2439168
blocks
> [ 939.889734] systemd-fsck[258]: /dev/xvda1: clean, 332/62248 files,
63868/248832
> blocks
> [FAILED] Failed to mount /var/vmail.
> See 'systemctl status var-vmail.mount' for details.
> [DEPEND] Dependency failed for Remote File Systems.
> Starting Trigger Flushing of Journal to Persistent Storage...
> Starting LSB: Prepare console...
> [ OK ] Started Trigger Flushing of Journal to Persistent Storage.
> [ OK ] Started LSB: NFS support files common to client and server.
> [ OK ] Started LSB: Prepare console.
> Starting LSB: Set console font and keymap...
> [...]
Do you have any further ideas?
Cheers,
jonas
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/558ea123.9050...@freesources.org
