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.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 27046 invoked from network); 24 Oct 2021 07:20:17 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 24 Oct 2021 07:20:17 -0000 Received: (qmail 24543 invoked by uid 89); 24 Oct 2021 07:20:43 -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 24536 invoked from network); 24 Oct 2021 07:20:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:date:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=aVhQB8nhjkHTX/lYM5LRaipXwhBv3b1ZdXxNZ2huFMo=; b=Qet5GyZg0FXPPKIS8/ShO5bAzr4f9ZOJjTDVG5Mhe9eyybGunHHwvH/4vNa4en9+V1 Q7+L0eIWpfYustSGM3+YVvKQb5JdtGu971EX8hjTGyVgkvDZr4ONR1nN7OpLcJD2NY4A VMG7FWz2uZDFyBZCo8U1WFLsbOpm88Dg2WuAFphodsQ+/6S2lOVKag1TvKRkYaD4Re4b rAM16fl7HafYWWD7E/G3jeZWajRWfPW/9keo92x9ir4FMgBu3cEqKi2HF7GxMhfnfzGb MUTA+CfX0A5MR5UBPTETyMzwvxGbmPlVwgGAuCLhw/RkCDEYOuEzOdGcsvQ0VnnuGK2F /TUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:date:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=aVhQB8nhjkHTX/lYM5LRaipXwhBv3b1ZdXxNZ2huFMo=; b=QlhiHmHZm5zJV9/KKkruxjliMTpirj3X9LunN71zEVCqzRPTp3vOrIAjsr1AIdEL/E QwqB+KBN/YzjbQTfIic5HuKQOHJkriNOasl98dnUKjPV97BAEXx6OknOSfuJ7ckVxeu2 TsBK1gNK/C5toRIA6T3d7/g0KUiFEJtu3WA3jf5xvULBEQ8tcXwd2XVijigTooyKi1uM ucr9Xew/lOozVXoJ4cVKUdxdgKS0FQhnqIJYuZHg6tmjXKxUScudIMOZexKo//yfCHad GHPs/rK36Gny87VpOKM6Oh/7jGXOBM8K8i5p+HmlARkzpDojeOguMnumVsQidKCaWiac yfwQ== X-Gm-Message-State: AOAM531J8ToowmdUtEu/BwDySJrf9GmUKeLl0YD1+SkkDOZvb59AHRkM 7HP2SN3+Jyc0jiwPxOkQzOyVT8ad6dzTFw== X-Google-Smtp-Source: ABdhPJzX2zl3Tcihf66k1uNMGBO4G9zlmSEQhrb9HGddTttyCkzcxtGQzuzAOeYBB18EIVgJXuRjJQ== X-Received: by 2002:a17:907:c0c:: with SMTP id ga12mr2237184ejc.173.1635060015109; Sun, 24 Oct 2021 00:20:15 -0700 (PDT) From: "Casper Ti. Vector" X-Google-Original-From: "Casper Ti. Vector" Date: Sun, 24 Oct 2021 15:20:09 +0800 To: supervision@list.skarnet.org Subject: Re: A program that can get exactly the log of a supervised process? Message-ID: Mail-Followup-To: supervision@list.skarnet.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: On Sun, Oct 24, 2021 at 06:20:53AM +0000, Laurent Bercot wrote: > So basically, either loggrep is a simple tee-like program but you > weaken the supervision properties of the service, or the functionality > needs to be embedded in the supervision architecture, with loggrep > being a consumer for service and a producer for logger (which is > easy with s6-rc but not so much with pure s6) and loggrep always > watching the state of service (which is not so easy with s6-rc, where > you don't know the full path to another service directory). Well, I do realise the lifespan issue of the loggrep program, which is why I asked the question in the first place. But I really never thought of directly inserting loggrep into the logging chain as a new node; instead, what I have thought is making loggrep a program "attachable" to the logger. That is, the logger is extended with a listener which at least one client can connect to, and which upon connection tees the log to the client. I do not know whether you have similar ideas. Additionally, I have just noticed a race condition in the origin design in my question. If loggrep is double-forked by an external program (execline or so), the daemon may become ready before loggrep is ready to receive logs; a better way is to let loggrep do the double fork itself, after the teeing pipe is ready. The downside is that errors deemed tolerable by the daemon but fatal by the user would then need to be explicitly handled by loggrep; but this is probably already over-design, so perhaps it just does not matter... -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C