On 2022-10-17 13:11, Laurent Bercot wrote:
>
> No, because these are operations that are ideally done at different
> times.
> - Compilation happens "offline", before you (re)boot the machine.
> - s6-svscan is run independently from s6-rc, typically very early
> during the boot sequence. (Ideally it's process 1.) In any case the
> preexistence of a supervision tree is assumed by s6-rc, so spawning
> one as part of an s6-rc command isn't good workflow.
> - Initialization happens when the service manager is ready to run,
> which means when the machine is online and already has an s6-svscan
> running.
I understand that these tools are executed at different times and we
want to make long-lived daemons as small as possible, that only do one
job. Perhaps a higher-level orchestration tool(s) is/are needed, that
will accomplish most typical workflows like:
- make changes in source -> complie -> switch symlink to latest compiled snapshot ->
s6-rc-update. In systmd world this is easier: edit -> systemd
daemon-reload
- list running services, start/stop them etc.
- auto-generating cooresponding logger service for a service. Today it
is mostly a copy-paste job and incompatible with vanilla svcscan
./log/run subdir approach, which is confusing on its own.
Another set of reasons for a high-level utility is better UX:
- today users have to interact with multiple binaries and remember all
their names, cli flags and positional parameters.
- there are no manual pages that would help with the point above, and
short help messages are not very useful. ( I often resort to reading
https://skarnet.org/software/s6 from my browser )
- CLI interface of those binaries is not very intuitive, and there are
no long options to improve readability in scripts.
Example: It is very hard to remember what this actually means
s6-log -d3 -- t s16777216 n64 /var/log/mysvc
I would much prefer something like this for all utilities, in
addition to short options
s6-log --notification-fd 3
--num-files 64
--filesize 16777216
--timestamp tai64
/var/log/mysvc
If changing CLI interface of s6 toolchest is not something that you
consider then a higher-level orchestration tool can take away some these
pains
> However, there's a change I can make that would immediately improve
> s6-rc's usability: since it's largely a perception issue, changing
> the vocabulary from "s6-rc-compile" to "s6-rc-snapshot" and
> "compiled database" to "opaque snapshot of the set of services" would
> be a good idea. It would spook fewer people, and send fewer people
> into red herring trains of thoughts. :)
If compiled snapshot was an opaque file, instead of a directory that
would indeed make the perception a bit better
Received on Mon Oct 17 2022 - 17:43:28 CEST