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 30003 invoked from network); 18 Oct 2022 00:58:10 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 18 Oct 2022 00:58:10 -0000 Received: (qmail 10776 invoked by uid 89); 18 Oct 2022 00:58:35 -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 10769 invoked from network); 18 Oct 2022 00:58:34 -0000 From: "Laurent Bercot" To: "supervision@list.skarnet.org" Subject: Re: s6-rc as user service manager Date: Tue, 18 Oct 2022 00:58:08 +0000 Message-Id: In-Reply-To: <20221017234905.4rrdwvrxs6pchfdx@localhost> References: <20221017175034.jmwoagcwrd6k4j2r@localhost> <8F72C59D-7F58-4084-94B4-CBEF75421327@disroot.org> <20221017234905.4rrdwvrxs6pchfdx@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 >Thanks Peter, this was actually helpful and enchanced my mental model. >I think I get get away for now with a user's tree rooted in the system >tree. My graphics environment (sway) can start necessary services >when it is started. Yeah, it's a recurring discussion on the IRC channels, and my answer is always that "user services" as systemd does them aren't a well- defined concept - "logging in" doesn't always have a clear meaning: do sshd logins count? Or only seat sessions? What happens when the same user logs in via 2 different seats and 1 sshd, then logs out of one seat? then of the second seat? Should the services be stopped, and if so, when? systemd has to make choices and makes things work, more or less, in the common case of one user at one seat - but that's a very unsatisfying answer from a developer's point of view. s6 users are also more likely to log in remotely more often than systemd users, so maybe systemd's choices aren't the best ones for s6. "User services" are a can of worms, and since I'm always very reluctant to enforce policy on users or make choices that will not work in all cases, it's not one that I'm willing to open beyond what's provided by s6-usertree-maker. I'm happy that you can work with a permanent user tree - that is a well-defined concept that can be implemented and wholeheartedly supported with s6. >By testing I meant checking if the directory has an active process >watching it. I believe there is a function in skalibs fd_lock [1] >that svscan uses to check if another svscan runs there. I think it is >just a matter of exposing that function as standalone executable. There are no executables to test whether s6-svscan or s6-rc are running on a given directory, because these are not dynamic properties. By policy, decided by you or your distro, you should *know*, at all times, whether a given directory is a scandir with an s6-svscan running on it - or whether a given directory is a livedir with s6-rc running on it. If you think a given directory should have an s6-svscan running on it, then you're right; ensure that s6-svscan is started at boot time, and write your scripts assuming that it's there. If something fails because it's not there, that's a bug or a system problem, and needs to be fixed, not accommodated by your scripts. -- Laurent