Re: systemd nfs mount blocked until first entered
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
Reply to: