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 <recovery...@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
>
>
