Re: Unable to get service to wait for a mount before starting

[Adam Nielsen <a.nielsen@xxxxxxxxxxx>]

I'm replying to all three messages in one to avoid spamming the list:

On Tue, 29 Oct 2024 21:39:12 +0300
Andrei Borzenkov <arvidjaar@xxxxxxxxx> wrote:

> > server:/path /mnt/server/path nfs4 x-gvfs-hide,noauto,x-systemd.automount,timeo=15,soft,proto=tcp 0 0
> > /mnt/server/path/subfolder /mnt/share none bind,_netdev,x-systemd.automount,x-systemd.requires=/mnt/server/path 0 0
> >   
> 
> x-systemd.automount makes no sense. You service has implicit Requires 
> mnt-share.mount that will trigger mounting of both filesystems on boot 
> anyway and won't have any idle timeout.

This is just for consistency.  I have around 10 shares from the same
NFS server so it's easier for maintenance to keep the options all the
same for them all.  If I remove x-systemd.automount then some of the
shares don't mount when I first access them.

> Instead of guessing you should have read the logs. I cannot reproduce it 
> (without using NFS) and educated guess is - you do not have proper 
> network-online.target implementation, so your NFS is attempted to be 
> mounted before network setup is finished and this attempt fails.

You're right, I should have read the logs.  The problem seems to be
that systemd is trying to mount the NFS shares before it has configured
DNS, so it fails because the hostname doesn't resolve.  So I will have
to figure out how to get systemd to properly wait until the network is
configured before trying to mount NFS shares.

I'm not sure what you mean by not having a proper network-online.target
implementation.  I'm using the one distributed with systemd.  There
aren't any other versions or overrides for it in use.  The unit in
question specifies "After=network-online.target".

On Tue, 29 Oct 2024 09:09:31 +0200
Mantas Mikulėnas <grawity@xxxxxxxxx> wrote:

> Units are only restarted when they are already running and their daemon
> process fails; they're never "retried" when conditions or dependencies
> change when the unit never reached 'starting' at all.
> 
> If systemd itself is responsible for the mount (i.e. there is a fstab entry
> or a .mount unit), then your service can have a dependency on it, and can
> be ordered to wait until the mount succeeds (either using explicit
> Requires= & After= on the .mount, or the combined RequiresMountsFor= that
> you already have).

You are right and this does appear to work.  The fact that the shares
were all available when I logged in was what made me think it was
running the code before the shares were mounted, but now I see systemd
was unable to mount the shares because the network hadn't been set up
yet.  But by the time I logged in systemd had finished setting up the
network and the shares auto-mounted, hiding the problem.

> But if the mount just randomly shows up by some external means, that won't
> happen – the .mount unit didn't exist at boot time, the dependency wasn't
> met and that's the end of story. In this case, you have to do the
> *opposite* – if you want systemd to react to the event of the mount showing
> up, then your service has to be a dependency of the mount.
> 
> Even externally established mounts have virtual .mount units in systemd, so
> if you want your service to be started by the *event* of /mnt/share being
> mounted, [Install] WantedBy=mnt-share.mount would achieve that.

I presume in this case if I stopped the service, then
unmounted/remounted the share, the service would start again
automatically?  That's not what I particularly want.  I don't want the
service to start in response to the share appearing, I'd like the service
to start at boot time and if the share has to be mounted in order for
that to happen, then for it to do so.

On Tue, 29 Oct 2024 08:06:21 +0000
Henti Smith <henti@xxxxxxxxxxxxxxxxx> wrote:

> I had a similar requirement and the way I implemented it was to create
> a systemd.mount for the NFS mount and then ensure that I have the mount in
> the "After" and add a " Requires" in the service that will depend on the
> mount. An example below:
> 
> After=network.target nfs.mount
> Requires=nfs.mount
> 
> I hope this helps.

Thanks for the suggestion!  It appears this is what the
RequiresMountFor= essentially does, so I should be able to get the same
result with that, once I figure out what's going on with the network.

Cheers,
Adam.