[systemd-devel] Submitting a service activation to remote mounts success

Thomas HUMMEL thomas.hummel at pasteur.fr
Tue Feb 6 15:15:27 UTC 2024


Hello,

I'm using systemd-239-74 on RHEL 8.8 EUS.

I was wondering if one can express the following :

start some service *only and only if/when* all remote mounts (ex: nfs, 
some parallel fs) has *succeeded*, taking into account it may take some 
time for some mount (some fs clients just live curl | sh themselves at 
start !) to finish (which seems to exlude usage of 
AssertPathIsMountPoint for instance, as it would not wait, or would it ?)

I have no auto option in the fstab for those fs and they use the _netdev 
option

Obvisouly I could statically list all the mounts units as an ordering 
dependency but this is not what I was looking for as there are namy (and 
I'm not even sure - see below - it it would be enough)

Exploring this question I stumbled upon the following points :

my understanding is that:

1. remote-fs.target special target is pulled in by multi-user.target and 
is added by systemd-fstab-generator as a Before= ordering dep to all 
remote .mount units

-> I also see a remote-fs.target has a Requires=<remote-mounts> 
activation dep : I probably missed it in the doc but I don't see this 
listed in neither implicit nor default dep : where does it come from ?

2. Before=/After= refer, in the case of service units, to when the unit 
has "finished starting up", this being defined by "when it returns 
failed or success", which is dependent of the Type= of the service

Is this understanding correct ?

But when the unit is of type mount : what's the semantic of Before/After 
? (I don't think I saw it in the doc neither)

What's the meaning/use of Type=none in a .mount unit ?

My experience is that the mount may fail and remote-fs.target will still 
be reached, even if one replace Requires with BindsTo, correct ?

So success or failure of the mount process does not seem to be involved 
in the ordering dep, or does it ?

Thanks for your help

-- 
Thomas HUMMEL


More information about the systemd-devel mailing list