systemd automount unit: run only when server is reachable

[Jürgen Bausa]

Using Linux now for a long time I am still not really familiar with systemd and have a
question on its usage. I am sure this is not the best place to ask it (I know, its off-topic),
But posting to other lists I didnt get an answer. So if you know a better place to ask it please
point me there.

I am using systemd automount units (see below) to mount network shares on my laptop
(debian bullseye). This works fine in principle but I have one big issue:

At home it is enough to set TimeoutSec to 2 s in the mount unit. Normally the server is
available and the share is mounted. If the server is down I need to wait for just 2 s
until I see it is not there. Thats ok.

But when not at home and using a vpn, the mount unit will not mount with TimeoutSec set to 2 s.
I need to set it to at least 10 s. Then the mount works. But using 10 s means I always have
to wait 10 s for each share the system tries to reach and is not available. This is really
annoying when starting libreoffice for example (which seems to check for the last used
documents on startup).

What I would like to do is to put a test for server availabilty (e.g. ping -c 1 $SERVER)
into the automount file. When the server is not available, automount is not run.
Is this possible? Or do I need to create a spcial unit and put something like

Requires=nfs-server-online.target

in my automount unit? And how would the nfs-server-online unit look like?

What I am doing at the moment is running a script that checks availability of the nfs server
every some seconds (via ping) and turns on/off the automount unit accordingly
(via systemctl start/stop mnt-share.automount). This works, but its not a very elegant solution.
I am pretty sure it can be done better using systemd only.

Regards,

Jürgen

/etc/systemd/system/mnt-share.automount:
[Unit]
Description=autoount share

[Automount]
Where=/mnt/share
TimeoutIdleSec=1min

[Install]
WantedBy=multi-user.target




/etc/systemd/system/mnt-share.mount:
[Unit]
Description=Mount share

[Mount]
Where=/mnt/share
What=lana:/share
Type=nfs
Options=soft,async
TimeoutSec=10

[Install]
WantedBy=multi-user.target

[Joe]

I have a number of shares (samba rather than nfs) listed in /etc/fstab
with the noauto and x-systemd.automount options, among others. Without
the noauto it will assume every fstab entry is required for booting and
will hang on boot if it can't find one. With both, it automounts at
first access, and therefore may never mount if it's not needed for
anything.

I would assume it would work similarly with nfs instead of cifs.

--
Joe

[Jürgen Bausa]

Hi Joe,

> Gesendet: Montag, 12. September 2022 um 19:05 Uhr
> Von: "Joe" <j...@jretrading.com>
> An: debia...@lists.debian.org
> Betreff: Re: systemd automount unit: run only when server is reachable

>
>
> I have a number of shares (samba rather than nfs) listed in /etc/fstab
> with the noauto and x-systemd.automount options, among others. Without
> the noauto it will assume every fstab entry is required for booting and
> will hang on boot if it can't find one. With both, it automounts at
> first access, and therefore may never mount if it's not needed for
> anything.
>
> I would assume it would work similarly with nfs instead of cifs.
>

It will. In fact systemd creates automount units from your fstab similar to the ones
I use. But the problem remains the same: If you want to use them over vpn
you need to the set the timout to a high number of seconds. Otherwise it will not
mount (should be the same for your fstab approach). And thus you have to wait for
a long time if the share is not reachable. Which occurs often with laptop that is not
only used in the home net and not always runs the vpn.

Regards,

Jürgen

[Darac Marjal]

systemd has a number of Condition* rules which can be added to units:
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Conditions%20and%20Asserts
You could maybe rig something up with that.

Alternatively, if the mount always takes at least 10 seconds, then that
sounds like it might be a DNS issue. I see that you're trying to mount
the host as "lana". If you're connecting over a VPN, it's likely that
you're not using the same DNS resolver as at home, so perhaps something
is timing out before it finally resolves. Do you get the same 10 second
delay if you mount the path at the command line? If you add "-v" to the
mount command, you might see the NFS client trying various options.

[john doe]

On 9/12/2022 7:05 PM, Joe wrote:
> On Mon, 12 Sep 2022 09:31:07 +0200
> Jürgen Bausa <Juerge...@web.de> wrote:
> >> I am sure this is not the
>> best place to ask it (I know, its off-topic), But posting to other
>> lists I didnt get an answer. So if you know a better place to ask it
>> please point me there.
>>

I would say the Systemd mailing list but this list is awsome and I'm
also guilty of being OT from time to time!

--
John Doe

[Jürgen Bausa]

> Gesendet: Dienstag, 13. September 2022 um 08:17 Uhr
> Von: "john doe" <johndo...@mail.com>

>
> I would say the Systemd mailing list but this list is awsome and I'm
> also guilty of being OT from time to time!
>

I already asked at systemd-devel, but got no answer. Is there another
systemd mailing list?

Jürgen

[Jürgen Bausa]

> Gesendet: Montag, 12. September 2022 um 21:06 Uhr
> Von: "Darac Marjal" <maili...@darac.org.uk>

> An: debia...@lists.debian.org
> Betreff: Re: systemd automount unit: run only when server is reachable
>

> systemd has a number of Condition* rules which can be added to units:
> https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Conditions%20and%20Asserts
> You could maybe rig something up with that.

Already looked at these. Unfortunately they all check fixed conditions. You cannot
run an arbitrary shell script. Only thing that would work is to run a script in
the background that creates a certain file, if the server is available. Then I could use
ConditionPathExists=. But thats again an ugly solution.

I found ExecCondition= in the docs. This option would do exactly what I want. But its allowed
only in the [Service] section which both mount and automount units dont have.

>
> Alternatively, if the mount always takes at least 10 seconds, then that
> sounds like it might be a DNS issue. I see that you're trying to mount
> the host as "lana". If you're connecting over a VPN, it's likely that
> you're not using the same DNS resolver as at home, so perhaps something
> is timing out before it finally resolves. Do you get the same 10 second
> delay if you mount the path at the command line? If you add "-v" to the
> mount command, you might see the NFS client trying various options.

DNS is not the issue. lana has a fixed IP and that ist written in the hosts file.
It takes so long beacuse of the internet connection. Depending on how far away you
are from your home server, I guess it would take even longer. I think its mainly
based on the latency of the line. Just did a test with manual mounting and it took
3.5 s. But when I tried some days ago it was much higher.

Jürgen

[Greg Wooledge]

The question that was asked in this thread seems on-topic to me. It was
about setting up systemd automount file systems on Debian. That's about
as on-topic as you can possibly be.

Unfortunately, I don't have any experience with systemd automount, so I
can't give much guidance. I will note that a 10 second timeout is
fairly short, as such things go.

[David Wright]

On Mon 12 Sep 2022 at 09:31:07 (+0200), Jürgen Bausa wrote:

> I am using systemd automount units (see below) to mount network shares on my laptop
> (debian bullseye). This works fine in principle but I have one big issue:
>
> At home it is enough to set TimeoutSec to 2 s in the mount unit. Normally the server is
> available and the share is mounted. If the server is down I need to wait for just 2 s
> until I see it is not there. Thats ok.
>
> But when not at home and using a vpn, the mount unit will not mount with TimeoutSec set to 2 s.
> I need to set it to at least 10 s. Then the mount works. But using 10 s means I always have
> to wait 10 s for each share the system tries to reach and is not available. This is really
> annoying when starting libreoffice for example (which seems to check for the last used
> documents on startup).
>
> What I would like to do is to put a test for server availabilty (e.g. ping -c 1 $SERVER)
> into the automount file. When the server is not available, automount is not run.
> Is this possible? Or do I need to create a spcial unit and put something like
>
> Requires=nfs-server-online.target
>
> in my automount unit? And how would the nfs-server-online unit look like?
>
> What I am doing at the moment is running a script that checks availability of the nfs server
> every some seconds (via ping) and turns on/off the automount unit accordingly
> (via systemctl start/stop mnt-share.automount). This works, but its not a very elegant solution.
> I am pretty sure it can be done better using systemd only.

I don't remember the details of the complaint, but there are
circumstances where systemd kills off jobs that it is controlling.

You could investigate using cron's @reboot to fire off a number
of tasks, each mounting one of the shares.

I use it myself to restart minidlna after I've got around to
decrypting and mounting /home, which could be any time or not
at all:

# crontab -l
# /root/.cron/crontab-axis last edited 2022-04-25
# Note that this is root's own crontab so it doesn't need the
# user field but it does require installing with crontab.

MAILTO= …

# check for (dist-)updated packages and provoke an email if any are in the cache
0 */3 * * * apt-get -qq -o Acquire::http::Proxy="http://192.168.1.14:3142/" update && apt-get -qq -d -o Acquire::http::Proxy="http://192.168.1.14:3142/" dist-upgrade && find /var/cache/apt/archives/ -name '*deb'

# restart streamer when mounting /home gives it access to served files
@reboot /root/.cron/mystreamers-restart.sh

… …

# cat .cron/mystreamers-restart.sh
#!/bin/bash
# /root/mystreamers-restart.sh last edited 2022-05-15
# wait for real /home to be mounted (its lost+found appears)
# read the directories to be served
# set the group permissions to allow minidlna to serve the files
# restart the service

Conf=/etc/minidlna.conf
Log=/var/log/minidlna/minidlna.log

while :; do
if [ ! -d /home/lost+found ]; then
sleep 60
else
if [ -f "$Conf" ]; then
sed -n '/^media_dir=/s/media_dir=//p' "$Conf" |
while read Served; do
chmod -R go=rX "$Served"
done
if [ -f "$Log" ]; then
date +'Root cron restarted %Y-%m-%d %H:%M:%S' >> "$Log"
fi
systemctl restart minidlna.service
fi
break
fi
done

#

Cheers,
David.

[Jürgen Bausa]

Hi David,

if I understood you correctly you propose to run a script in the background to check for
the condition I am interested in (is the nfs server available?) and do the changes accordingly.

In fact I am doing this at the moment. But I think its an ugly hack and thought a better solution
should be possible with systemd only. E.g. in my case I have to check the availabilty of the server
every some seconds (same as in your script), while in fact it does need to be checked only in the
case the share is to be mounted. That would be much more elegant and efficient.

Seems systemd is still not used very much actively. I mean most people run it, but they dont write
their own stuff for it. When looking for information on shell scripts, I normally find the solution
on google after 1 min. In case of systemd I googled a long time with no result and even posting to
different mailing lists/forums did not help.

Regards,

Jürgen

> Gesendet: Dienstag, 13. September 2022 um 20:13 Uhr
> Von: "David Wright" <deb...@lionunicorn.co.uk>

[David Wright]

> if I understood you correctly you propose to run a script in the background to check for
> the condition I am interested in (is the nfs server available?) and do the changes accordingly.

If by "do the changes" you mean mount the shares.

> In fact I am doing this at the moment. But I think its an ugly hack and thought a better solution
> should be possible with systemd only. E.g. in my case I have to check the availabilty of the server
> every some seconds (same as in your script), while in fact it does need to be checked only in the
> case the share is to be mounted. That would be much more elegant and efficient.

On Demand might work for your use case, where I assume you have
control over whatever is demanding access to the resource.
I've not used it, but autofs seems to have what are termed
"executable maps", which might be coerced into running a ping
script that, if it fails, aborts the mounting operation.

But I can't see the point in the system waiting until you
want a share before it attempts to see if it's there and
mounts it. What does it gain you? It's not like a USB stick,
where the system doesn't even know it exists until plugged in.

I would want the shares to be there, ready when I reference
them. That's efficient for the user. I couldn't care less
about the machine making such an efficiency saving.

On Demand wouldn't work with the example I showed. If I select
Roku Media Player on the TV, the streaming port, 8200, has to
be available already, or the TV won't display that host.
Mounting a new directory at that time, and then restarting the
server, would kick the Player off that host, and make you
have to connect to it again.

> Seems systemd is still not used very much actively. I mean most people run it, but they dont write
> their own stuff for it. When looking for information on shell scripts, I normally find the solution
> on google after 1 min. In case of systemd I googled a long time with no result and even posting to
> different mailing lists/forums did not help.

I'm not sure what writing stuff for it includes. Usually I don't
have to do much more than copy a /lib file to /etc and tweak it.
If I needed a new one, I'd just copy and modify the one that
looked closest to what I wanted (programming by example).

As for shell scripts, do you mean those in /etc/init.d/?
In the past, I found that distributions varied so much in
how they were written that most "solutions" were outdated
or didn't match up with the scripts in Debian. Even if you
understood some of these scripts, others were just as opaque
at first sight, because it's difficult to enforce a standard
on them.

There's a fair quantity of systemd man pages now:
$ find /usr/share/man/man* -name \*systemd\* | wc -l
187
$
and I found the http://0pointer.de Systemd for Administrators
a very useful introduction in the early days (available by the
time jessie was released) when man pages were thinner on the
ground, IIRC.

Cheers,
David.