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
