Re: A program that can get exactly the log of a supervised process?

From: Rio Liu <rio.liu_at_r26.me>
Date: Mon, 25 Oct 2021 12:57:39 +0000

Why not have the grepper listen on the log file directly? You'll need to have a timestamp in the log and know where the log is, but those can be known at the time of writing the service script.

--------原始郵件--------
在 2021年10月25日 08:37, Laurent Bercot 寫道:

>>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
Received on Mon Oct 25 2021 - 14:57:39 CEST

This archive was generated by hypermail 2.4.0 : Mon Oct 25 2021 - 14:58:16 CEST