Re: Some wishes for s6-log & s6-envdir

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Thu, 26 Feb 2015 19:37:32 +0100

On 02/26/15 18:43, Laurent Bercot wrote:
>
> I fully agree with Colin on both points.
>
> - For the s6-envdir thing: all the tools already exist to perform
> what you want. Sure, adding an option isn't hard, and would make
> things convenient, but it's a slippery slope. I try to provide
> tools that perform basic operations and rely on users to combine
> them to get the results they want. If I start adding options here
> and there to minimize the number of executables you have to call,
> what is convenience, what is redundancy, and what is outright
> bloat ? Those are questions I'd rather not have to ask myself
> all the time.

I get it. Although the option to use a clean environment feels (to me)
like it belongs to s6-envdir, otherwise we can't guarantee that the
environment we'll get won't be polluted from the original one.
Yes, emptyenv allows do do that, but that's a little besides the point.
It's not like there aren't more than one way/tool to do the same thing
already, exec also allows to clear the environment after all.

I don't feel strongly about it that I'll push this anymore, but just
saying I feel this option makes sense on its own, not just to reduce the
number of executable to call, but because s6-envdir is used to define an
environment, having a way to guarantee what said environment will be
seems a good/logical thing.


> - For the s6-log thing: prepending a line with a string is
> definitely work for a processor. A trivial sed one-liner at
> that. If you need processing after s6-log has forwarded a
> line, pipe it into another program.

But you're missing one thing here: I don't want to simply add a prefix,
I want to do that *after* the whole selection bit happened, and so
conditionally.

Otherwise I'd then need to maintain the regex to identify the lines in
both locations: service logger (s6-log) to send the line to stdout/fifo,
and then in the service reading from that fifo to determine what line
this is/prefix to use.

I would really like to avoid this. A simple sed one-liner makes sense
only if I know what the line is. In s6-log I do, because it was selected
via regex already, but with an external service I don't and need to
re-implement that whole step again...
So if sed can work it's certainly not a one-liner anymore.


As an example: imagine the service is openvpn. I want the logger to log
everything of course, but also id lines for when the connection is
established (vpn is up/service is ready), and when it's down (vpn is
down/service is not ready anymore, though still up ofc).
This can happen many times over the life of the service, and I want to
have a specific event/trigger when it goes up (ready), and another one
when it goes down (non-ready).

In s6-log I can select each line via regex and send both to some fifo
(via 1), but if I didn't add a prefix I don't know which event this is.
Now I could of course send all lines to that fifo and do the selection
there, but then we're saying s6-log's selection feature is useless, and
needs to be reimplemented elsewhere to be used?

The prefix directive was a simple way to benefit from the selection
feature by giving control over the output (log line, prefixed log line,
or only the prefix even).
A more complete solution would be a processor indeed, but, as in Colin's
example, that has to be an integrated part of/as a processor of s6-log
to remain a simple one-liner and benefits from the regex selection feature.

> Sure, the "p" option you're suggesting is a simple one, it
> would be easy to implement, but then again, where to stop ?
> Why limit ourselves to fixed strings ? Why not a more elaborate
> format ? Slippery slope again - I'd rather draw the line
> early and keep line modifications outside of s6-log.

I get that, but one could say that it allows to fully benefit from the
selection feature of s6-log. One could also point out that even you saw
an interest in such a prefix, only making it hard-coded and required
when using 2, and unusable when using 1.

Maybe it would be simpler (and more powerful obviously) to have 1 and 2
behave exactly the same, only on fd 1 or 2 is all.
No more special "s6-log: alert: " prefix for 2 only, because there's a
(non-sticky, a-la timestamps) control directive to set a prefix, so one
can decide which prefix to use if any, on 1 and/or 2, and of course
while benefiting from the selection feature to use different prefixes as
needed!

(For extra bonus there's "P" which like "p" but only use the prefix,
without the log line after it.)
Received on Thu Feb 26 2015 - 18:37:32 UTC