From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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: from alyss.skarnet.org (alyss.skarnet.org [95.142.172.232]) by inbox.vuxu.org (Postfix) with SMTP id 1E58C2EF7F for ; Wed, 4 Dec 2024 22:58:33 +0100 (CET) Received: (qmail 57850 invoked by uid 89); 4 Dec 2024 21:58:59 -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 57843 invoked from network); 4 Dec 2024 21:58:59 -0000 From: "Laurent Bercot" To: supervision@list.skarnet.org Subject: Re[2]: Have an external script wait for a oneshot service Date: Wed, 04 Dec 2024 21:58:28 +0000 Message-Id: In-Reply-To: References: <20241204140015.4e635037306d88117e053994@freesa.org> <2571a89b-ac74-4d9e-b8c6-ff0fe05cebb7@sopka.ch> <20241204141821.ee2a00c996c948f2feb42dec@freesa.org> Reply-To: "Laurent Bercot" User-Agent: eM_Client/10.1.4588.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable >Although it would be nicer to have a standard way to do this There is a standard way to block until a oneshot has completed: depend on that oneshot. Duh. The thing is, s6-rc wasn't designed to have external scripts interacting in this way with this engine, because if you have programs depending on intermediary s6-rc states, they should be managed by s6-rc as well. The point is to have a predictable machine state when s6-rc exits; if you have random other stuff doing things in parallel, that defeats the purpose. And with an s6-linux-init setup, at boot time there is no other process than s6-rc managing your services. You have the supervision tree, and the stage 2 script, and that's it. And if you're going to spawn stuff in your rc.init that waits for oneshot X in the s6-rc db, then... why? Why not have said stuff as another service? If you cannot, for whatever reason, maybe bring your services up in two steps? s6-rc change X && stuff & s6-rc change default And if all else fails, the generic solution would be to have a oneshot Y depending on X (so, that would run once X is done) that sends a notification to a place of your choice via a mechanism of your choice, you could use a fifodir and s6-ftrig-notify for this. You would still have to deal with the race conditions around setting up the listener=20 etc. The cleanest way to achieve what you want, without support in the service set itself, is to s6-rc change X first, then s6-rc change the rest of your services. That way, you avoid breaking abstraction with hacks of questionable aesthetic value. -- Laurent