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