Re: systemd automount unit: run only when server is reachable
On Wed 14 Sep 2022 at 10:34:23 (+0200), Jürgen Bausa wrote:
> > Gesendet: Dienstag, 13. September 2022 um 20:13 Uhr
> > Von: "David Wright" <deblis@lionunicorn.co.uk>
> >
> > 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
> >
> > #
>
> 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.
Reply to: