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 26750 invoked from network); 23 Oct 2021 16:03:15 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 23 Oct 2021 16:03:15 -0000 Received: (qmail 8891 invoked by uid 89); 23 Oct 2021 16:03:40 -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 8884 invoked from network); 23 Oct 2021 16:03:40 -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:mime-version :content-disposition; bh=iutzRgxZu9bfMU/iUG8GvibW0jUVCFZWmT8mnhy4Gqc=; b=cycEx1y4Z96fs32tjIRWqzau7GbJZehLD2kzR4NFNkeBWBM4Ez82vv18lT+Bg2OQb9 uddN7VnzWG1k0c7UTMKjDx/0MQ/kBR8r4fb/U3sqMPQlfuSmJDFv5A+h+fNvSqJWUDcR J4U3s/c8OMO+nUF37ELQgrBc2U3B1N1zYxWT7JXfny5c1cnJ3Ymi/vxYd9/jXtaMnm2n nzjNFkjHxi2amzsra4m4Cc4tley5dYRnKae8mulhGNPQt+38nZkwRT9Y4jwrZqESKOMc zmtC8Gk8RoX2mWjibe9q86UEysbQMgjWq32KdU2yd7nQ+U9qVSNF+EduQzL/XTXQPUTB 3Cbw== 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 :mime-version:content-disposition; bh=iutzRgxZu9bfMU/iUG8GvibW0jUVCFZWmT8mnhy4Gqc=; b=21L5+1qsHJSy82ZZeLTD2i2pidLARrKiPbZzhJFbyN8haop3Frh6sFlHTFtXCSCDSA DSystZuEAKH//zZ8tzkMEvvNo0GjwrB6UpJV5+2RFEuLYz/AVh5ZDCp2POw8hK+WWIgg C4qIO+GR2jUMg+CV/IeuLSywIcHoXvxhMD53RlxnbvXLAK175jN2e5qIbjVbf9hpFI6e Xdt5ZMVMrqDIBMt6Wo6+w2IB39oerNFIPpSixZVIdhKcU/Io+AsQMJ87tKGoLDfO97qP qhpdxK4e+50ZMBIQeTbAj3CB4Ku/WskpYHrgJ3jGlD3ljZTUMYKqHIT6Lij3oM3SFFfq vdpw== X-Gm-Message-State: AOAM532y0IFZrGy53tsyQOPmJqSBv6jhxyGGsfXnSbk2auhicWPTIzfU glJGf4gy739tEs9RQ1irqFIvDIZW0qOsoA== X-Google-Smtp-Source: ABdhPJxo+pudDfJuFx/LlP5XvjRAOd80Ih6mfzU6TRr3+rzjBcsHG5N480v83EGk39ZAtwDBIEzN1w== X-Received: by 2002:a05:6a00:1312:b0:44c:becf:b329 with SMTP id j18-20020a056a00131200b0044cbecfb329mr6950667pfu.5.1635004991365; Sat, 23 Oct 2021 09:03:11 -0700 (PDT) From: "Casper Ti. Vector" X-Google-Original-From: "Casper Ti. Vector" Date: Sun, 24 Oct 2021 00:03:01 +0800 To: supervision@list.skarnet.org Subject: A program that can get exactly the log of a supervised process? Message-ID: Mail-Followup-To: supervision@list.skarnet.org MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Many daemons output some lines in their logs (here assumed to have been redirected to logging pipes in some supervision framework) that can be used as a kind of markers for readiness. So if we can implement the following program, we will able to trivially add readiness support to these daemons without patching their source code, while reducing the daemon-specific code (the pattern recogniser) to a minimum: * The program is double-forked from the ./run script of a service, and also watches for the death of the daemon: in case the daemon dies before logging the readiness marker (and optionally, if a specified timeout is reached), this program dies as well, killing its subprocess (the pattern recogniser, discussed below). To maximise portability across supervision frameworks, the death notification can be implemented with a pipe that can be written to by an ancillary program ran from the ./finish script. * The program somehow (directly or indirectly) gets a copy of the log from the reading side of the logging pipe, and feeds it into a specified pattern recogniser, which should exit 0 upon finding the readiness marker. A special exit value of the subprocess can be considered a notification for fatal error erroneously ignored by the daemon, leading to the program exiting some special value which can be handled by a `s6-svc -t' invocation. In order to avoid potential feedback loops, the subprocess should be killed (and waited for) before the program outputs any warning; the subprocess should be responsible for keeping itself quiet when running normally. Any idea on how the log "teeing" may be done cleanly (and portably if possible; something akin to `tail -f' seems unsuitable because of potential log rotation), and perhaps any flaw or redundancy in the design above? -- My current OpenPGP key: RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20) 7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C