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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15849 invoked from network); 25 Oct 2021 12:37:44 -0000 Received: from alyss.skarnet.org (95.142.172.232) by inbox.vuxu.org with ESMTPUTF8; 25 Oct 2021 12:37:44 -0000 Received: (qmail 7706 invoked by uid 89); 25 Oct 2021 12:38:08 -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 7699 invoked from network); 25 Oct 2021 12:38:07 -0000 From: "Laurent Bercot" To: "Casper Ti. Vector" , supervision@list.skarnet.org Subject: Re: A program that can get exactly the log of a supervised process? Date: Mon, 25 Oct 2021 12:37:41 +0000 Message-Id: In-Reply-To: References: Reply-To: "Laurent Bercot" User-Agent: eM_Client/8.2.1659.0 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable X-VR-SPAMSTATE: OK X-VR-SPAMSCORE: -100 X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedvtddrvdefhedghedvucetufdoteggodftvfcurfhrohhfihhlvgemucfpfgfogfftkfevteeunffgpdfqfgfvnecuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufffkjghfrhgfgggtgfesthhqredttderjeenucfhrhhomhepfdfnrghurhgvnhhtuceuvghrtghothdfuceoshhkrgdqshhuphgvrhhvihhsihhonhesshhkrghrnhgvthdrohhrgheqnecuggftrfgrthhtvghrnheptdefkeeuteeikeethfevueevvedtkeegfefhueetvdeiieehudeuieduhedvteevnecuffhomhgrihhnpehskhgrrhhnvghtrdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmohguvgepshhmthhpohhuth >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. Well in theory you could have something like skabus-dyntee ( https://skarnet.org/software/skabus/skabus-dyntee.html ) as your logger, and have your "real" logger run as a skabus-dyntee client. Then you could add a loggrep as a second skabus-dyntee client, and it would just disappear when it has finished its work. It would be a little unreliable as is, because skabus-dyntee doesn't care if it has no client at all, so if the real logger dies, it won't block the log stream until the real logger has restarted, so you may lose logs. But apart from that, it would work. A really reliable solution would be having a skabus-dyntee equivalent that has one permanent output and blocks as long as that output isn't there. As you say, it would be a logger extended with a listener. Another question is how to piggyback loggrep into the notification mechanism: if loggrep is tied to the logger and not to the service, it doesn't have native access to the notification pipe. That means a specific mechanism is needed to give it cross-service access. That's definitely a lot of code and a lot of architectural convolutions to accommodate what is ultimately a daemon misdesign. But it's probably the least bad way to do it, so I might think about it more and add something like that to s6 in the distant future. -- Laurent