Re: systemd nfs mount blocked until first entered
On Fri, Jul 02, 2021 at 07:46:31PM +0200, Reiner Buehl wrote: > I think I found a solution! For whatever reason, my network interface > enp5s11 was not in the "auto" line in /etc/network/interfaces. After adding > it there and a reboot, the filesystem is mounted correct without any of > the x-systemd mount options. This happens a *lot*.
Re: systemd nfs mount blocked until first entered
I think I found a solution! For whatever reason, my network interface enp5s11 was not in the "auto" line in /etc/network/interfaces. After adding it there and a reboot, the filesystem is mounted correct without any of the x-systemd mount options. Am Fr., 2. Juli 2021 um 19:30 Uhr schrieb Reiner Buehl < reiner.bu...@gmail.com>: > 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 : > >> 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 >> >>
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 : > 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 > >
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
Re: systemd nfs mount blocked until first entered
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. The mount > is done via an /etc/fstab entry like this: > > 192.168.1.2:/video /video nfs > defaults,x-systemd.automount,x-systemd.requires=network-online.target,x-systemd.device-timeout=10,rsize=8192,wsize=8192,soft,nolock,noatime > 0 0 That's a lot of options. I wonder what they all do. If you simply boot the machine and then login and run 'df', do you see the file system mounted? I'm wondering in particular about that x-systemd.automount option. Does that mean something like "don't mount this until I think someone really wants it"? https://manpages.debian.org/buster/systemd/systemd.automount.5.en.html says that these are "activated when the automount path is accessed", but it doesn't say what counts as "accessed". I wonder if removing the x-systemd.automount option would help you. The other thing you'll want to look at is how your network interface is configured. You've got x-systemd.requires=network-online.target which *sounds* reasonable, but only if the network interface is actually configured to be waited upon. If you're using /etc/network/interface (the Debian default) for your interface config, make sure the interface is marked as "auto", rather than as "allow-hotplug". The latter causes systemd NOT to wait for the interface. Make sure it says "auto" instead.
