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.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 7299 invoked from network); 25 Oct 2022 09:29:58 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 25 Oct 2022 09:29:58 -0000 Received: (qmail 31020 invoked by uid 89); 25 Oct 2022 09:30:22 -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 31013 invoked from network); 25 Oct 2022 09:30:21 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re: Disconnect between s6-svscan and s6-rc Date: Tue, 25 Oct 2022 09:29:54 +0000 Message-Id: In-Reply-To: <20221024233412.4pcy3baje2ly6lsr@localhost> References: <20221024233412.4pcy3baje2ly6lsr@localhost> Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.1.2109.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >The user of s6-rc gets no error message, and waits forever. >The error message is captured by s6-svscan (or a corresponding logger >for that service) and is either saved into a log file, or printed to a >tty on which svscan is running. >The user is almost never on the same tty with svscan. The user never >gets an error message from the service, unless they explicitly know >where to look. There's no "tty on which svscan is running". s6-svscan should not run in a terminal. You *can* do it, but it's fragile: it means your whole supervision tree is vulnerable to a ^C in a terminal. The output of s6-svscan, and the supervision tree by default, should go to a catch-all logger and potentially to the system console. >It would be nice if a user can get a temporary view into the service's >stdout for the short duration of s6-rc execution? Such that when s6-rc >never exits waiting we can see what the error message that service >prints? For oneshots, it is the case: the output of oneshots will go to the output of s6-rc. Unfortunately, for longruns, that's pretty difficult. One of the points of supervised longruns is that they're always started with the exact same environment, and that includes their descriptors. That means they're outputting to the same place whether or not s6-rc is running. In order to temporarily display error messages from longruns, s6-rc would have to find out where the catch-all logger is, and display it to the user while it's running. That's impossible while s6-rc is independent from s6 policy. Unified policy for better interaction between tools in the toolset is one of the goals for s6-rc v1, which is still a long ways away. For now, my advice would be to always use a timeout when running s6-rc (you will have an error message if it times out), and/or to have the supervision tree's output on the system console, and have the reflex to check the console when you feel that s6-rc is taking more time than it should. Sorry I don't have any better immediate solution. -- Laurent