On Sun, Oct 24, 2021 at 06:20:53AM +0000, Laurent Bercot wrote:
> So basically, either loggrep is a simple tee-like program but you
> weaken the supervision properties of the service, or the functionality
> needs to be embedded in the supervision architecture, with loggrep
> being a consumer for service and a producer for logger (which is
> easy with s6-rc but not so much with pure s6) and loggrep always
> watching the state of service (which is not so easy with s6-rc, where
> you don't know the full path to another service directory).
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.
Additionally, I have just noticed a race condition in the origin design
in my question. If loggrep is double-forked by an external program
(execline or so), the daemon may become ready before loggrep is ready to
receive logs; a better way is to let loggrep do the double fork itself,
after the teeing pipe is ready. The downside is that errors deemed
tolerable by the daemon but fatal by the user would then need to be
explicitly handled by loggrep; but this is probably already over-design,
so perhaps it just does not matter...
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2022.09.20)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Sun Oct 24 2021 - 09:20:09 CEST