Re: Have an external script wait for a oneshot service

[Paul Sopka]

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:

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.


The easy way out of this is to have all "interface-software",

But I would argue that this is not an elegant solution:

- A user might not have setup user-services,


- Even a user with user-services set up would have to wait


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


I argue that this is more elegant.

A readiness api for oneshots would help with this.

Regards

Paul

software that's timing is controlled by the user and that is part of the interface. Now of course the script should only be ran after the the "s6-rc-init" oneshot. e.g. agetty, greetd, sshd, etc. depend on a bundle containing L and O of each user.   why should he have to wait for all the other user-service-trees to be prepared?   for all the other user-trees to be prepared too, which might take longer to start than his. the waiting time would only affect the user starting slow starting user-services.

OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature