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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3287 invoked from network); 3 Jan 2024 12:35:39 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 3 Jan 2024 12:35:39 -0000 Received: (qmail 30051 invoked by uid 89); 3 Jan 2024 12:36:03 -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 30044 invoked from network); 3 Jan 2024 12:36:03 -0000 From: "Laurent Bercot" To: Sertonix , supervision@list.skarnet.org Subject: Re: s6-rc: dependencies across scandirs Date: Wed, 03 Jan 2024 12:35:37 +0000 Message-Id: In-Reply-To: References: Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.2.2157.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >Hi, I would like to have some kind of dependency handling across >multiple scandirs. > >For example an instanced service that starts and waits for a dependency >before the first instace has been started. It's generally a bad idea to add, in a service's run script itself, conditions for your service to work, or to restart. It tends to make your service *less* reliable, instead of *more*. Supervision is about keeping the services up, not monitoring when they should or should not run. The latter is for service management. Instead, design your services so they exit if they have unmet hard dependencies. The supervisor will try to bring them up again and again, and it will eventually work, when the dependencies are resolved. The job of avoiding too much looping, again, belongs to a service manager. >A more complicated variation I would like to have is a user service >depending on a system service (and starting it!). For example a user >service for sway depends on the system service for seatd. Start your sway. If seatd isn't up, sway will exit, and the supervisor will restart it. This works as intended. Now, start propagation is a different question, and a more difficult one, because it crosses privilege boundaries. Do you want users to be able to start system services? To stop them? In the general case, no, you certainly don't. In this particular case, you probably want seatd to be controllable by the user at the console. That's what s6-svperms is for: https://skarnet.org/software/s6/s6-svperms.html When relevant (at user login time? earlier?) make seatd controllable by a group only the console user is in. Then you can simply add a s6-svc -u for seatd in your sway run script, if that's what you need. -- Laurent