[systemd-devel] Unable to get service to wait for a mount before starting

[Mantas Mikulėnas]

On Tue, Oct 29, 2024 at 4:50 AM Adam Nielsen <a.nielsen at shikadi.net> wrote:

> Hi all,
>
> I'm having some problems getting a systemd unit to start during system
> boot.  Can anyone advise what I'm doing wrong?
>
> The service starts fine if I run `systemctl start myservice`, the issue
> is that it fails to start during boot.
>
> The service runs off a network share, so if it starts too early in the
> boot process the share is not mounted and it fails for that reason and
> systemd does not try to restart it later, despite the unit file saying
> to restart forever.
>

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

(The RequiresMountsFor would internally expand to [Unit]
Requires=mnt-share.mount After=mnt-share.mount, or something along those
lines.)

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.

-- 
Mantas Mikulėnas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241029/053d3fca/attachment.htm>