Re: Have an external script wait for a oneshot service

[Paul Sopka]

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?

and lacking dependency management (see Hoël's mail).

Besides, I suppose one being this:

It is one oneshot less, at the cost of running s6 only and s6-rc services side by side

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.



(note the paths / filenames being only exemplary)



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.

Finally, I believe to have found (thanks to our discussion making me think) an even better solution: 1.    Have a system-longrun create/mount /run/user/${USER} tmpfs and start s6-svscan on /run/user/${USER}/service

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
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature