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

2024-02-07 Thread Thomas HUMMEL




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

2024-02-07 Thread Andrei Borzenkov

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

2024-02-07 Thread Andrei Borzenkov

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

2024-02-07 Thread Thomas HUMMEL




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

2024-02-07 Thread Thomas HUMMEL




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

2024-02-06 Thread Demi Marie Obenour
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

2024-02-06 Thread Silvio Knizek
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


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

2024-02-06 Thread Thomas HUMMEL

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= 
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