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
