>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:37:41 CEST