Re: Have an external script wait for a oneshot service

[Paul Sopka]

 Exactly. That's the YAGNI principle: don't try to solve problems you
haven't encountered yet. Chances are you'll actually never encounter
them. Adding complexity in the name of "just in case" is overengineering
and it will only worsen your design.

We now have two examples of application from the other mails.

 And if I have learned anything about users, it's that most of your
users will have trouble understanding what a supervised service is,
and if you start talking about them about s6-rc services, their brain
will start melting and they'll run away from your system as fast as

they can. And they won't be wrong.

When I talked about "users", I mean people actually *using* these tools,

Thus I do not consider them, since they will never interact with
service management directly anyway.

I therefore try to make life as easy as possible for power users
and distribution maintainers, who manage their own supervision trees
or setup the presets for said managed distros respectively.

meaning s6, s6rc, execline, POSIX tools, ... hence power users and distribution maintainers. People using their computers only to consume media or write documents (whom I will refer to as consumers), will use Windows, MacOS or, in the best case, a highly managed Linux distro anyway.

 The user has a supervision tree. They can install their longrun directly
in it. They don't need s6-rc for that. Pure s6 is enough.
 Their service will run as long as they keep it there. They can stop

it with s6-svc. Or s6-svunlink.

Assuming s6-rc is used for the main supervision tree and on login,
which is fair, since the very thing we discuss about is part of my project
doing all of that with s6-rc,
this would cause users to need to learn s6 additionally to s6-rc,
when s6-rc can be used for all cases.

 You want to run s6-rc at login time, sure, I can totally see where i
can be beneficial there. But earlier? Even systemd doesn't run user
stuff before a user logs in. And if *they* don't do it, it means that
there are ZERO use cases.

This is an argumentum ad verecundiam.
Systemd is fundamentally flawed in other places too.

 And what is preventing that? The fact that your default bundle does not
include the services that the user has defined themself. This should give
you a hint that this design goes against what supervision is supposed to
be doing, and thus, that it's not a good design. Whatever longrun the
user wants to have survive a reboot should survive a reboot and the

one (1) call to s6-svlink, it works: after a reboot, the snooze will

user shouldn't need a PhD to accomplish that.  If the user has installed their service in the pure s6 way with e.g. be back up.

We have, due to my poor wording, a misunderstanding here:
Said "default" bundle is part of the user's user-tree,
it is entirely under his control and offers the user a way to have
user-services started at boot time.

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.

and running s6-rc for each user-tree at boot.

Or let s6-rc-init and s6-rc do this work, by adding the service to the user-tree bundle "default"

 It's more inconvenient, complex and inconsistent because you want to
keep the framework that makes it so. Remove a little more and you'll
have something elegant again.

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

 Little to no cost? This whole thread is about the costs! And from my
perspective, "probably going to be useful at some point" is a pretty
light argument, it's definitely not going to outweigh "too complex to

make work properly".

The cost is, quoting myself, one(mutually exclusive) of the following:

- S1    Script s6-fifodir functionality in bot the system-oneshot 1b/2c and the script L.

- S3    Have the script L do the same as system-oneshot 1b/2c:

        - 1bii/2cii    Start "s6-rc-init -b" and "s6-rc start login".

- S2    Add a readiness api for s6-rc oneshots like s6 longruns have and wait for that of system-oneshot 1b/2c in the script.         - 1bi/2ci    Prepare the live directory for the user-tree (preferably under /run/user/${USER}).   Utilizing blocking locks and tests to work parallel to system-oneshot 1b/2c.   This can only be done if the script is ran through PAM, since 1bi/2ci requires root privileges.

I do not see where this exceeds "little".

Regards

Paul

OpenPGP_0x71C7C85A2EA30F62.asc
Description: OpenPGP public key

OpenPGP_signature.asc
Description: OpenPGP digital signature