>1. First we create 'scandir1', and put services there. Each service is a
> svcdir. We put dependencies file and type file in each svcdir.
> (We do not run svcscn on it, because it doesn't really manage
> dependencies)
That's a bad reason. :)
The real reason why you don't run s6-svscan on a source s6-rc directory
is because it's not a suitable scan directory. It doesn't contain
service directories: it contains s6-rc definition directories, which
may be for longruns (and in this case *look like* service directories
but they're not, for instance the "run" file doesn't have to be
executable), but also for oneshots or bundles, and s6-svscan would not
know how to deal with those. And they have dependency information,
which s6-svscan cannot interpret, etc.
Even if their formats are similar, a source directory and a scan
directory are not the same and aren't used for the same purposes.
>2. We run s6-rc-compile pointing at scandir and get 'compiled' dir as
> output.
>
>3. We run svcscan process on an emtpy dir - 'scandir2'
>
>4. We run s6-rc-init , feeding 'compiled' and 'scandir2' dirs we
> get 'live' dir.
>
>At this point things seem to be working and I can use s6-rc to bring up
>and down services with dependencies.
That is indeed the correct way to proceed.
> But this gets very confusing and
>does not look like a good user experience:
I agree it's confusing, and one of the reasons (but not the main one)
why s6-rc needs a redesign: you currently get access to all the internal
workings of the service manager, even when they're not relevant to you,
which is not ideal.
>So same information is duplicated 3 times and symlinked 3 times.
>Is this the intended flow? Or have I messed something up really badly?
It's the intended flow, and the information duplication is necessary.
- The source directories are where you, the user, edit the information.
It's your working copy of it. You should be able to change it as you
wish; the modifications you make should not impact the system.
- The compiled directory is where the information is stored when
s6-rc-compile validates your source directories. It's an automation-
approved snapshot of the state of your source directories at the time
you called s6-rc-compile. It is immutable: neither you, nor the system
can modify it - and you can store it on a read-only filesystem. The
point is that once you have it, and it works once, it will *always*
work.
- The live directory is the working copy of the *system*. It manages
what is going on *right now* on your machine. Some of it is symbolic
links to a compiled directory, when the system only needs to read
information; but some of it is state that can be changed by the system
and that needs to be a copy. That includes longrun service directories,
that maintain running state, which is why these need to be copied
from the compiled directory.
Having this duplication is the only way of ensuring that your
modifications do not change the snapshots you take when compiling and
do not impact the current machine state, and also that the operation
of your current services does not impact the set of services you're
booting on (which could lead to failed boots).
Other service managers do not make the distinction between the
user working set, the system working set, and immutable snapshots; that
is a big issue I have with them, because it's difficult to make them
safe.
Hope this helps,
--
Laurent
Received on Sun Oct 16 2022 - 12:39:17 CEST