On 17/03/2016 19:20, Jan Bramkamp wrote:
> I want to arrange multiple s6-log processes into a tree with pipes as
> edges and forward filtered log lines from leaves towards the root.
> Reading the s6-log documentation[1] I found that it stops forwarding
> messages to stdout after the first write error and clutters lines
> written to stderr with a warning.
>
> Is there some deeper reason to permanently break the logging chain
> after the first I/O error?
There's a simple reason: a write error is likely not recoverable, so
stdout is likely forever broken after the error. Even if it is not, s6-log has
no way of knowing, and the only alternative would be to store logs in memory
until stdout is healthy again, which may well never happen, in which case
s6-log would run oom.
stderr is a different case: it's not meant for normal data flow, messages to
stderr are supposed to be the exception, and they actually rely on stderr never
blocking (else the whole program blocks). The alert prefix is an indicator
that stderr is not suited for verbatim log forwarding.
> Is there any chance for a patch changing this behavior to be accepted?
No, sorry. The "forward to stdout" option is a feature I added because it was
the least ugly solution to a problem a few users were having, but I looked
long and hard to make it as reliable as possible and it's the only thing that
worked.
The only change of behaviours I would consider would be making the s6-log
process die on a write error on stdout: it's the other way to guarantee that
no logs are ever lost.
s6-log was always meant to be a logging backend, not a logging frontend; it
already does a lot, too much for a pure backend, and any additional
non-backend feature would likely require a reorganization and a split into
two separate programs. I hope it will not be necessary.
To implement your logging tree, you could use a program such as tee, or
Paul Jarc's multitee (
http://code.dogmap.org/fdtools/multitee/) for the
tree's nodes, and s6-log for the leaves only.
Alternatively, if your tree is a comb, you could use s6-log's -1 option as
you intended, and use a fdholder to maintain both ends of the pipes open
so you'd never get a write error.
--
Laurent
Received on Thu Mar 17 2016 - 19:31:34 UTC