Re: [systemd-devel] Submitting a service activation to remote mounts success
On 2/7/24 19:55, Andrei Borzenkov wrote: You can add drop-in to either unit (and add generator to do it automatically), but I do not quite see what is it going to buy you. Hello, thanks for your answer and sorry for the previous confusions I made. What do you call generator here ? A custom script to generate the dropped-in files or some systemd mechanism (I then must admit I still don't know yet) ? What I want (though I don't like to over use systemd dependencies as I instinctively think this may not be a good idea), is to prevent an hpc scheduler daemon (service unit) to accept jobs if remote mounts (mandatory for consistent use) are not all here (successfully mounted) The initial idea, which avoided listing (or generating) every mounts one by one was to express dependencies relative to remote-fs.target by adding BindsTo=remote-fs.target to the service (After= comes for free) But then if some such .mount units would get unmonted remote-fs.target's Requires= would not deactivate remote-fs.target and my service would in turn not be deactivated Thanks for your help -- Thomas HUMMEL
Re: [systemd-devel] Submitting a service activation to remote mounts success
On 07.02.2024 19:20, Thomas HUMMEL wrote: On 2/7/24 11:50, Thomas HUMMEL wrote: Still I cannot understand where the Requires= comes in remote-fs.target unit as doc for special target only describes a Wants= dep added by systemd-fstab-generator in the case of auto mounts. Well, forget about that Wants= dep which is to the mount unit. Basically my only remaining question is: is there a way to have remote-fs.target BindsTo= instead of Requires= only ? You can add drop-in to either unit (and add generator to do it automatically), but I do not quite see what is it going to buy you.
Re: [systemd-devel] Submitting a service activation to remote mounts success
On 07.02.2024 13:50, Thomas HUMMEL wrote: Still I cannot understand where the Requires= comes in remote-fs.target unit It is generated by systemd-fstab-generator as doc for special target only describes a Wants= dep added by systemd-fstab-generator in the case of auto mounts. If doc for special target is systemd.special, I do not see even that in https://www.freedesktop.org/software/systemd/man/latest/systemd.special.html.
Re: [systemd-devel] Submitting a service activation to remote mounts success
On 2/7/24 11:50, Thomas HUMMEL wrote: Still I cannot understand where the Requires= comes in remote-fs.target unit as doc for special target only describes a Wants= dep added by systemd-fstab-generator in the case of auto mounts. Well, forget about that Wants= dep which is to the mount unit. Basically my only remaining question is: is there a way to have remote-fs.target BindsTo= instead of Requires= only ? Thanks for your help -- Thomas HUMMEL
Re: [systemd-devel] Submitting a service activation to remote mounts success
On 2/6/24 17:06, Silvio Knizek wrote: Hi Thomas, RequiresMountsFor=3D should be your friend. It just takes a space- separated list of paths and does all the other stuff by itself. Hello, thanks for your reply. Actually RequiresMountsFor is not what I need because I'd have to point some file *inside* the fs. I mistakenly did my tests on a noauto mount which made me draw false conclusions. In fact what I need is just a Requires= ou BindsTo=remote-fs.target in my service unit file. Still I cannot understand where the Requires= comes in remote-fs.target unit as doc for special target only describes a Wants= dep added by systemd-fstab-generator in the case of auto mounts. Thanks for your help -- TH
Re: [systemd-devel] Submitting a service activation to remote mounts success
On Tue, Feb 06, 2024 at 05:06:02PM +0100, Silvio Knizek wrote: > Am Dienstag, dem 06.02.2024 um 16:15 +0100 schrieb Thomas HUMMEL: > > Hello, > >=20 > > I'm using systemd-239-74 on RHEL 8.8 EUS. > >=20 > > I was wondering if one can express the following : > >=20 > > start some service *only and only if/when* all remote mounts (ex: nfs,= > =20 > > some parallel fs) has *succeeded*, taking into account it may take some= > =20 > > time for some mount (some fs clients just live curl | sh themselves at= > =20 > > start !) to finish (which seems to exlude usage of=20 > > AssertPathIsMountPoint for instance, as it would not wait, or would it ?) > >=20 > > I have no auto option in the fstab for those fs and they use the _netdev= > =20 > > option > >=20 > > Obvisouly I could statically list all the mounts units as an ordering=20 > > dependency but this is not what I was looking for as there are namy (and= > =20 > > I'm not even sure - see below - it it would be enough) > >=20 > > Exploring this question I stumbled upon the following points : > >=20 > > my understanding is that: > >=20 > > 1. remote-fs.target special target is pulled in by multi-user.target and= > =20 > > is added by systemd-fstab-generator as a Before=3D ordering dep to all= > =20 > > remote .mount units > >=20 > > -> I also see a remote-fs.target has a Requires=3D=20 > > activation dep : I probably missed it in the doc but I don't see this=20 > > listed in neither implicit nor default dep : where does it come from ? > >=20 > > 2. Before=3D/After=3D refer, in the case of service units, to when the un= > it=20 > > has "finished starting up", this being defined by "when it returns=20 > > failed or success", which is dependent of the Type=3D of the service > >=20 > > Is this understanding correct ? > >=20 > > But when the unit is of type mount : what's the semantic of Before/After= > =20 > > ? (I don't think I saw it in the doc neither) > >=20 > > What's the meaning/use of Type=3Dnone in a .mount unit ? > >=20 > > My experience is that the mount may fail and remote-fs.target will still= > =20 > > be reached, even if one replace Requires with BindsTo, correct ? > >=20 > > So success or failure of the mount process does not seem to be involved= > =20 > > in the ordering dep, or does it ? > >=20 > > Thanks for your help > > Hi Thomas, > > RequiresMountsFor=3D should be your friend. It just takes a space- > separated list of paths and does all the other stuff by itself. > > Another options would be to switch to x-systemd.automount in fstab for > the network shares, so they will be mounted on first access, not > necessary during early boot when there is no network. FYI, it looks like your mailer used quoted-printable encoding, but didn’t set the appropriate headers to indicate that this encoding is in use. -- Sincerely, Demi Marie Obenour (she/her/hers) Invisible Things Lab signature.asc Description: PGP signature
Re: [systemd-devel] Submitting a service activation to remote mounts success
Am Dienstag, dem 06.02.2024 um 16:15 +0100 schrieb Thomas HUMMEL: > Hello, >=20 > I'm using systemd-239-74 on RHEL 8.8 EUS. >=20 > I was wondering if one can express the following : >=20 > start some service *only and only if/when* all remote mounts (ex: nfs,= =20 > some parallel fs) has *succeeded*, taking into account it may take some= =20 > time for some mount (some fs clients just live curl | sh themselves at= =20 > start !) to finish (which seems to exlude usage of=20 > AssertPathIsMountPoint for instance, as it would not wait, or would it ?) >=20 > I have no auto option in the fstab for those fs and they use the _netdev= =20 > option >=20 > Obvisouly I could statically list all the mounts units as an ordering=20 > dependency but this is not what I was looking for as there are namy (and= =20 > I'm not even sure - see below - it it would be enough) >=20 > Exploring this question I stumbled upon the following points : >=20 > my understanding is that: >=20 > 1. remote-fs.target special target is pulled in by multi-user.target and= =20 > is added by systemd-fstab-generator as a Before=3D ordering dep to all= =20 > remote .mount units >=20 > -> I also see a remote-fs.target has a Requires=3D=20 > activation dep : I probably missed it in the doc but I don't see this=20 > listed in neither implicit nor default dep : where does it come from ? >=20 > 2. Before=3D/After=3D refer, in the case of service units, to when the un= it=20 > has "finished starting up", this being defined by "when it returns=20 > failed or success", which is dependent of the Type=3D of the service >=20 > Is this understanding correct ? >=20 > But when the unit is of type mount : what's the semantic of Before/After= =20 > ? (I don't think I saw it in the doc neither) >=20 > What's the meaning/use of Type=3Dnone in a .mount unit ? >=20 > My experience is that the mount may fail and remote-fs.target will still= =20 > be reached, even if one replace Requires with BindsTo, correct ? >=20 > So success or failure of the mount process does not seem to be involved= =20 > in the ordering dep, or does it ? >=20 > Thanks for your help Hi Thomas, RequiresMountsFor=3D should be your friend. It just takes a space- separated list of paths and does all the other stuff by itself. Another options would be to switch to x-systemd.automount in fstab for the network shares, so they will be mounted on first access, not necessary during early boot when there is no network. BR Silvio
