Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #236767 > unrolled thread

systemd nfs mount blocked until first entered

Back to article view | Back to linux.debian.user

Contents

  systemd nfs mount blocked until first entered Reiner Buehl <reiner.buehl@gmail.com> - 2021-07-02 18:40 +0200
    Re: systemd nfs mount blocked until first entered Greg Wooledge <greg@wooledge.org> - 2021-07-02 19:10 +0200
    Re: systemd nfs mount blocked until first entered Reco <recoverym4n@enotuniq.net> - 2021-07-02 19:20 +0200
      Re: systemd nfs mount blocked until first entered Reiner Buehl <reiner.buehl@gmail.com> - 2021-07-02 19:50 +0200
        Re: systemd nfs mount blocked until first entered Reiner Buehl <reiner.buehl@gmail.com> - 2021-07-02 20:10 +0200
          Re: systemd nfs mount blocked until first entered Greg Wooledge <greg@wooledge.org> - 2021-07-02 20:30 +0200

#236767 — systemd nfs mount blocked until first entered

[Multipart message — attachments visible in raw view] — view raw

Hi all,

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

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

 vdr.service - Video Disk Recorder
   Loaded: loaded (/etc/systemd/system/vdr.service; enabled; vendor preset:
enabled)
  Drop-In: /etc/systemd/system/vdr.service.d
           └─override.conf
   Active: failed (Result: exit-code) since Thu 2021-07-01 23:27:25 CEST;
8h ago
  Process: 523 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh commands
(code=exited, status=0/SUCCESS)
  Process: 533 ExecStartPre=/bin/sh /usr/lib/vdr/merge-commands.sh reccmds
(code=exited, status=0/SUCCESS)
  Process: 543 ExecStart=/usr/bin/vdr (code=exited, status=2)
 Main PID: 543 (code=exited, status=2)
Jul 01 23:27:25 vdr systemd[1]: Starting Video Disk Recorder...
Jul 01 23:27:25 vdr vdr[543]: [543] ERROR: can't access /video
Jul 01 23:27:25 vdr vdr[543]: vdr: can't access video directory /video
Jul 01 23:27:25 vdr systemd[1]: vdr.service: Main process exited,
code=exited, status=2/INVALIDARGUMENT
Jul 01 23:27:25 vdr systemd[1]: vdr.service: Failed with result 'exit-code'.
Jul 01 23:27:25 vdr systemd[1]: Failed to start Video Disk Recorder.

The vdr.service has an override of

[Unit]
After=remote-fs.target
Requires=remote-fs.target

to ensure that the filesystem is mounted.

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.

What is systemd doing here that blocks the mount point for the vdr process?
Do I need different fstab options?

Best regards,
Reiner

[toc] | [next] | [standalone]

#236768

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.

[toc] | [prev] | [next] | [standalone]

#236769

	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

[toc] | [prev] | [next] | [standalone]

#236772

[Multipart message — attachments visible in raw view] — view raw

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
>
>

[toc] | [prev] | [next] | [standalone]

#236776

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#236777

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*.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web