Re: Have an external script wait for a oneshot service

Paul Sopka <[email protected]> Thu, 5 Dec 2024 07:54:15 +0100
Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<[email protected]>
>>> and that if you want to monitor it that way, you should
>>> use a regular service.
>> This is not possible, since what I depend on is a script that does its
>> thing and exits.
>> I would need to add a "sleep infinity" or better, a posix compatible
>> alternative at its end,
>> which would cause a useless dangling longrun being supervised and logged
>> - a waste of resources.
> Why don’t you use another oneshot? ^^
>
> Hoël 

>  The thing is, s6-rc wasn't designed to have external scripts
> interacting in this way with this engine, because if you have programs
> depending on intermediary s6-rc states, they should be managed by s6-rc
> as well. The point is to have a predictable machine state when s6-rc
> exits; if you have random other stuff doing things in parallel, that
> defeats the purpose.
>
>  And with an s6-linux-init setup, at boot time there is no other
> process than s6-rc managing your services. You have the supervision
> tree, and the stage 2 script, and that's it. And if you're going to
> spawn stuff in your rc.init that waits for oneshot X in the s6-rc db,
> then... why? Why not have said stuff as another service?
>
>  If you cannot, for whatever reason, maybe bring your services up in
> two steps?
>      s6-rc change X && stuff & s6-rc change default
>
>  And if all else fails, the generic solution would be to have a oneshot
> Y depending on X (so, that would run once X is done) that sends a
> notification to a place of your choice via a mechanism of your choice,
> you could use a fifodir and s6-ftrig-notify for this. You would still
> have to deal with the race conditions around setting up the listener etc.
>
>  The cleanest way to achieve what you want, without support in the
> service set itself, is to s6-rc change X first, then s6-rc change the
> rest of your services. That way, you avoid breaking abstraction with
> hacks of questionable aesthetic value. 
I wholeheartedly agree to this in respect to init.
But due to my foolish attempt to keep the discussion more general,
there is a confusion here. This is not about anything close to init,
But software that can not be part of the supervision tree:
software that's timing is controlled by the user and that is part of the 
interface.
To be more precise, I have the following setup:

- A longrun L setting up s6-svscan for a user-service-tree.

- A oneshot O setting up "s6-rc-init" and "s6-rc start default".

(two allow users to have services running on boot without login)

- A script run on login (bee it by PAM, .profile or another way),
   that starts user services only useful after login, e.g. pipewire.

Now of course the script should only be ran after the the "s6-rc-init" 
oneshot.
The easy way out of this is to have all "interface-software",
e.g. agetty, greetd, sshd, etc. depend on a bundle containing L and O of 
each user.
But I would argue that this is not an elegant solution:

- A user might not have setup user-services,
   why should he have to wait for all the other user-service-trees to be 
prepared?

- Even a user with user-services set up would have to wait
   for all the other user-trees to be prepared too, which might take 
longer to start than his.

Now if the script had a nice way to wait for O of the user logging in
to be started, the login software would not need to wait for O itself and
the waiting time would only affect the user starting slow starting 
user-services.

I argue that this is more elegant.

A readiness api for oneshots would help with this.

Regards

Paul
OpenPGP_0x71C7C85A2EA30F62.asc (application/pgp-keys, 3.1 KB)
OpenPGP_signature.asc (application/pgp-signature, 840 B)