From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26376 invoked from network); 17 Oct 2022 15:43:08 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 17 Oct 2022 15:43:08 -0000 Received: (qmail 28218 invoked by uid 89); 17 Oct 2022 15:43:33 -0000 Mailing-List: contact supervision-help@list.skarnet.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Received: (qmail 28211 invoked from network); 17 Oct 2022 15:43:33 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antonovs.family; s=20200215; t=1666021377; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Z38FvLn3JRESHgfB84ySJ0ouJUTVpekCP93WCBQnEfQ=; b=Vo0V9bznpFwxYfKrGdm/EAKnPDU/WOXJ9ZwqX/AjHRLWbWhAoErPTKiabXBcg5ej62w/Iu QecHfDqt/A34kGDQPjQNT1yuHddGpYqEjtJWJOn4qYu/zhZb+3QvBQczWp8pl9Mk9MOAkc DU1Djg6E6Q3usC8RNHMlVWCZRASQgvI= Date: Mon, 17 Oct 2022 08:43:28 -0700 From: Ihor Antonov To: Laurent Bercot Cc: supervision@list.skarnet.org Subject: Re: s6-rc user experience question Message-ID: <20221017154328.xcf35bdlabow6bjo@localhost> References: <20221016062822.ohngiq54sr2qhti3@localhost> <20221016160228.bypf5lyje6wfvbnc@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: 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