On Sun, Oct 24, 2021 at 12:03:01AM +0800, Casper Ti. Vector wrote:
> Any idea on how the log "teeing" may be done cleanly (and portably
> if possible; something akin to `tail -f' seems unsuitable because of
> potential log rotation), and perhaps any flaw or redundancy in the
> design above?
The recordio program is extremely enlightening here:
* Instead of trying to communicate with the logger, our program can
directly sit between the service and the logging pipe.
(This also solves the lifespan issue cleanly, saving lots of code;
the latter is apart from the lots of code to talk with the logger.)
* When forking, we may let the parent (instead of the child) exec()s
into the service, so our program does not need to forward signals.
(But the loggrep subprocess from our program may die after the
supervisor receives SIGCHLD from the service; therefore in order
not to interfere with the next run of the service, we should ensure
the loggrep program would exit on EOF and does not produce spurious
outputs on its stdout.)
The source code of the program, logtee (licence: CC0), is available at:
<
https://cpaste.org/?fa30831511a456b7=#ECwUd1YaVQBLUokynQbRYZq5wvBvXXeXo3bQoeL2rL4L>
It may be tested with (logtee is itself init-agnostic; writing an
adapter to, for instance, s6, should be an easy exercise in the
manipulation of argv):
------------------------------------------------------------------------
#!/bin/execlineb -P
fdmove -c 3 1
logtee {
fdmove 1 3
if { timeout 3 grep -q "bytes from" }
echo
}
fdclose 3
fdmove -c 2 1
ping -i 10 example.com
------------------------------------------------------------------------
--
My current OpenPGP key:
RSA4096/0x227E8CAAB7AA186C (expires: 2024.09.30)
7077 7781 B859 5166 AE07 0286 227E 8CAA B7AA 186C
Received on Thu Jun 22 2023 - 19:44:19 CEST