Re: systemd nfs mount blocked until first entered

Hello,

this is the full unit:

# /etc/systemd/system/vdr.service
[Unit]
Description=Video Disk Recorder

Wants=systemd-udev-settle.service
After=systemd-udev-settle.service

[Service]
Type=notify
ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "commands"
ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh "reccmds"
ExecStart=/usr/bin/vdr
Restart=on-failure
RestartPreventExitStatus=0 2

[Install]
WantedBy=multi-user.target

# /etc/systemd/system/vdr.service.d/override.conf
[Unit]
After=remote-fs.target
Requires=remote-fs.target

I only added the x-systemd options to /etc/fstab because the filesystems where not mounted at boot time at all with the old fstab options that I used before the upgrade to Debian (I did use yavdr before - a distro that was based on a super old 12.x version of Ubuntu). There I just used

192.168.1.2:/video /video nfs defaults,rsize=8192,wsize=8192,soft,nolock,noatime 0 0

If I try with this entry, the auto-generated video.mount unit fails as it seems to be started too early:

● video.mount - /video
Loaded: loaded (/etc/fstab; generated)
Active: failed (Result: exit-code) since Fri 2021-07-02 19:26:02 CEST; 2min 46s ago
Where: /video
What: 192.168.1.2:/video
Docs: man:fstab(5)
man:systemd-fstab-generator(8)

Jul 02 19:26:02 vdr systemd[1]: Mounting /video...
Jul 02 19:26:02 vdr mount[403]: mount.nfs: Network is unreachable
Jul 02 19:26:02 vdr systemd[1]: video.mount: Mount process exited, code=exited, status=32/n/a
Jul 02 19:26:02 vdr systemd[1]: video.mount: Failed with result 'exit-code'.
Jul 02 19:26:02 vdr systemd[1]: Failed to mount /video.

Best regards,

Reiner

Am Fr., 2. Juli 2021 um 19:15 Uhr schrieb Reco <recoverym4n@enotuniq.net>:

Hi.

On Fri, Jul 02, 2021 at 06:12:58PM +0200, Reiner Buehl wrote:
> I have a directory that is mounted via NFS from a remote server.

Actually, you have an autofs mountpoint, because you set
x-systemd.automount option in fstab.
Only if something starts using that mountpoint an NFS filesystem should
be mounted there.

In another words - you do not require your NFS filesystem to be mounted
at boot time, and thus remote-fs.target does not include your NFS
filesystem.

> If I boot the vdr daemon fails during startup with the error message

In other words, vdr fails to trigger automounting of the filesystem in
question. As usual with journald, the actual reason of this is not
present in this log.

> The vdr.service has an override of
>
> [Unit]
> After=remote-fs.target
> Requires=remote-fs.target
>
> to ensure that the filesystem is mounted.

These dependencies are useless for your service given the current state
of your fstab.
The reason being - "autofs" filesystems belong to local-fs.target, not
remote-fs.target, and explicitly depending on local-fs.target is useless
anyway (it's one of the default dependencies for the most units).
What you probably need here is a dependency for a .mount unit
corresponding to your NFS filesystem.

> If I try to restart vdr.service, it fails again with the same error but if
> I just cd to the directory and then try to restart it, it starts and works
> fine.

Can you show the result of "systemctl cat vdr" please?

> What is systemd doing here that blocks the mount point for the vdr process?

Many things are possible here. You have ProtectSystem=full set in unit,
or you have PrivateMounts=true set in there.

> Do I need different fstab options?

It depends. x-systemd.automount is useful, because it does not require
your NFS server to be present at boot time.
I'll refrain from suggesting certain hacks for now, I'd like to see your
unit in full first.

Reco