Re: Have an external script wait for a oneshot service

Paul Sopka <[email protected]> Fri, 6 Dec 2024 18:14:10 +0100
Newsgroups	gmane.comp.sysutils.supervision.general
Message-ID	<[email protected]>
First of all, if you get tired of this discussion, just tell me and I 
will stop bothering you.
I, for my part, experience great joy from this discussion!

If you are still interested, here you go:

>  And both can be solved without s6-rc in a simpler way than with it.
Why do you think it is simpler?
It is one oneshot less, at the cost of running s6 only and s6-rc 
services side by side
and lacking dependency management (see Hoël's mail).

Besides, I suppose one being this:

>> fusermounting some network/encrypted filesystem comes to mind.
>> e.g. mount a NAS share so that a longrun snooze "cronjob" can record a
>> livestream to it.
>
>  Okay. I'd argue it's still under the complexity line where doing
> this manually - fuser(un)mounting at snooze service (de)installation
> time - is easier and faster than setting up an s6-rc infrastructure. 
But this to me seems like saying "why not mount devfs in the longrun 
starting mdevd/udevd?"

>  Yeah. So do I. Do you have any idea how difficult it is to make
> distribution maintainers adopt the s6 paradigms? Change their habits
> even a little bit? Do you have any idea of the inertia I've had to
> bump against, again and again? When I tell you "make this simpler",
> it's not because Joe Schmoe won't understand your stuff. It's because
> Power Maintainer Dan J. Hacker won't want to jump through two hoops
> so you better make sure there's only one.
I can only imagine. But that's why I am doing this,
so that everybody like minded can have a working base structure to use 
s6/s6-rc.

>  If that really was what you're trying to do, you'd listen to me.
I listen to you and I really try to understand your point,
I am just not convinced (yet?).

>  Look, I *like* s6-rc. I'm happy that you like it too. I'm happy that
> you want to use it. I'm happy when people use my stuff. Don't get me
> wrong. But what I like even more is when the right tool is used for a
> job, in the right place, with the right glue. That's what makes life
> simpler for everyone, truly. 
I wholeheartedly agree, our disagreement lies somewhere else.

>  The vast majority of services a user will want to have are longruns.
> And longruns are run under s6; longrun service definition directories
> are pretty much s6 service directories. I don't think it's honest to
> say "you only need to learn s6-rc, not s6"; the s6-rc learning curve
> *includes* learning at least the fundamentals of s6.
I fully agree, scrap what I have written concerning this.
I want to mention though what always using s6-rc makes the experience 
more consistent.

> But I'm not adding hooks to s6-rc to
> support notification of intermediary states to external programs, because
> I simply don't believe it's how it should be used. 
I respect that.


I would be interested in what you think about the other points in my 
previous mail, especially:

> I have assumed that the scan-directory of the user-tree is mounted tmpfs.
> This would require additional support in 1a/2a
> to save the state of the scan-directory on shutdown and load it on boot.
> Or let s6-rc-init and s6-rc do this work, by adding the service to the 
> user-tree bundle "default"
> and running s6-rc for each user-tree at boot. 

> What is the "little more" you are talking about? 

> I do not see where this exceeds "little".
and whether:

> I have assumed that the scan-directory of the user-tree is mounted tmpfs. 
Is a good idea in the first place.


Finally, I believe to have found (thanks to our discussion making me 
think) an even better solution:
(note the paths / filenames being only exemplary)

1.    Have a system-longrun create/mount /run/user/${USER} tmpfs and 
start s6-svscan on /run/user/${USER}/service

2.    Have an (optional) oneshot do the following:

        a) Take a lock on /run/user/${USER}/s6-rc-lock

        b) If { /run/user/${USER}/s6-rc does not exist } s6-rc-init

        c) s6-rc start default

3.    Have the login script

        a) Take a lock on /run/user/${USER}/s6-rc-lock

        b) If { /run/user/${USER}/s6-rc does not exist } s6-rc-init

        c) s6-rc start login

This does not require waiting for a system-oneshot,
it allows people like you to not have s6-rc run for users on boot
and allows people like me to manage it everything with s6-rc.
Additionally it cleanly decouples boot user-s6-rc from login user-s6-rc,
in that the latter do not require the former to be prepared.


> so who am I to say otherwise.
You are the creator of the best pieces of software I could discover on 
the internet so far.
Thank you for writing it!

Regards

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