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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,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 1CEA92B73D for ; Thu, 5 Dec 2024 07:00:06 +0100 (CET) Received: (qmail 5108 invoked by uid 89); 5 Dec 2024 06:00:31 -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 5098 invoked from network); 5 Dec 2024 06:00:31 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1733378403; x=1733983203; darn=list.skarnet.org; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=GS4xIbIpleWdbd7DEothCvgXX+fjO/ou64W7qaePsYc=; b=QXhf5BgNUd3/ihSBv+VHAa4lpt/1+kvCUGEDlWPBrGZLw90LrwkscoiZ/ypR9lx+GQ iVuDhCSsBdG2XgGg87YzIvrrxhE+vK3Xk7sVz/AJhj7MJnKb7AoIdH4iknOPs3bC+Fc7 px/Ug2Ikg3L2vvsid3Ww/I0pmxojSNcTSwo5R1LjtBDZgy+DYYiMVfK+TOTehLUNZFmv kXHyW+NTnC22FJJWRD/Fq5poRPEdtutQZPzQwhkI7nrlcYIz5RXOuJaubMtQ0X6NaOay 789NfYT6aZPPPWFcKMGjxXvTWnBISmFUo301ngB1tIyrQfTf9vcEncuJ69PXHrBBFy2c 2GHA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1733378403; x=1733983203; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=GS4xIbIpleWdbd7DEothCvgXX+fjO/ou64W7qaePsYc=; b=npg6EKQWmW8KL+Ph1aEwiG3QuwrInw+pixDNG1PGBHfimUwQ4grjh8U2Fz2QOFT3LO Kt41Z65x7KVVzDZa4yjeuTtGpNuhbNATfOPziXyXXHQv4kH4URkjwie5jATJAcyEbZX/ nMQmq333+fj05UC+tuR0137k9p03aPz13b5Fr5gzi47L2M1TrdnoYcKBybmrPpFs5yMh Wir6DcaxGTs9d8y96gHi0UbiN6NquMw65K0r3Q4UFi0u0tVN4s4oriUigK2jbGOCioPn 1rmwpsikFPhDoMvmEpK0HsKnWDdKYMRxV62NZDz79Y1pKk3cg7wrk/7GqPahln3L5U8z u1yw== X-Gm-Message-State: AOJu0Yy7wisoJcw7qC1u1ZuScwsUH7LJYnXnoqlxjp7n0OhicVoZZN+K IfwFf1r0qRhGPCBRHlLMA60Nex00t8X3wOoRXf8EST31E9MzfUMJNfn23o5l X-Gm-Gg: ASbGncunKxfegQRJCrxCX3pKaoj8g3+Xn2dLnyoPyFV1ftOrD2Zwpa55cvoAIYZuPIY Pw7fSvc4nEsn1hCgezX9H1ZtBhdEyfDx9nJCYk71+LCOzVmka7uaopbAgiba87wRNAeOuc1L5d6 cDdoRxWb2T0RBjkoBvu6EQ4gP8UsiBBskLMVEKTh9yf7ydjDWTY/j2AF800KpJv/P41x8Zs8QlC YEE1RqQwkrH6S9UCeAjmuLV9/KkVw1LFfOdP1nnekDl9CJHTIYSqpDaUl4= X-Google-Smtp-Source: AGHT+IHavbpTD3c3GJwItDuyhbrAt7/kx10J+dl4eiENsJgElVyUTUO0bSNz4o2pkaHKKF1kVPftkw== X-Received: by 2002:a17:906:30c2:b0:aa5:3023:bae5 with SMTP id a640c23a62f3a-aa5f7d1fbb9mr698735966b.21.1733378402962; Wed, 04 Dec 2024 22:00:02 -0800 (PST) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Tanuj Bagaria Mime-Version: 1.0 (1.0) Subject: Re: Have an external script wait for a oneshot service Date: Thu, 5 Dec 2024 09:59:50 +0400 Message-Id: References: Cc: supervision@list.skarnet.org In-Reply-To: To: Laurent Bercot X-Mailer: iPhone Mail (22B91) unsubscribe > On 5 Dec 2024, at 01:58, Laurent Bercot wrot= e: >=20 > =EF=BB=BF >>=20 >> Although it would be nicer to have a standard way to do this >=20 > There is a standard way to block until a oneshot has completed: > depend on that oneshot. >=20 > Duh. >=20 > 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. >=20 > 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? >=20 > If you cannot, for whatever reason, maybe bring your services up in > two steps? > s6-rc change X && stuff & s6-rc change default >=20 > 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 etc. >=20 > 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. >=20 > -- > Laurent >=20