On Wed, Feb 25, 2015 at 4:32 PM, Olivier Brunel <jjk_at_jjacky.com> wrote:
> On 02/26/15 01:06, Colin Booth wrote:
>> On Wed, Feb 25, 2015 at 3:06 PM, Olivier Brunel <jjk_at_jjacky.com> wrote:
>> /bin/emptyenv -p s6-envdir /path/to/env exec
>> should be good enough. It's still an extra command over what you're
>> looking for, but as long as you don't flush the PATH environment
>> variable, you should know what you have coming.
>
> Except that the original environment might either not have a PATH set,
> or even possibly an "invalid" one. I don't want to use/keep it, but rely
> on the one defined in /path/to/env instead.
> I want the environment used to be the one defined in /path/to/env,
> without anything from the original one (not even PATH).
>
Good point. If you want to definitely use the one in /path/to/env,
drop the -p. Assuming you've built skalibs with the "correct" path,
you should pick up default one long enough to make it to when you load
your new env dir. If you haven't, there's going to be a bit where
absolute paths are required.
>
>>> - s6-log: I'd like a control directive to set a prefix, that would be
>>> printed before the actual log line. E.g. with
>>> p "s6-log: alert: " 1
>>>
>>> One would get the same as 2 only on stdout. Not that that is very
>>> useful, but I have a few loggers that can send some lines to a fifo for
>>> them to be processed, and such a prefix would allow me to e.g. specify
>>> the service name before the log line (as well as a simpler way to ID the
>>> event, to save parsing the line again).
>>>
>> That's doable now using stdin/stdout editors. For example, the
>> reference syslog replacement runs s6-ipcserver that spins up
>> ucspilogd's to catch each type of message going through /dev/log.
>> Doing this for any service probably involves having your service log
>> to a fifo instead of s6-log, then writing a log decorator service that
>> reads that fifo, decorates it with your prefixes, and then passes it
>> along to s6-log for management. Generally speaking though, it's easier
>> on the brain to output to /$logdir/$servicename instead of having to
>> look inside of the files for information.
>
> Well, I don't just want a decorator for log lines. In my case, I want
> the logger of a service, an s6-log, to log all lines to a logdir (indeed
> /var/log/$service), but also select some specific lines (corresponding
> to specific "events") and write them to its stdout as well, which is a
> fifo where said lines will be further processed (e.g. exec a script or
> something).
>
> But I'd like them prefixed, as multiple loggers (for different services)
> will write to that fifo, so it will make things easier to know what line
> it is/where it's from.
>
> I suppose I could e.g. use gawk to process log lines, write to the fifo
> when needed and always write the log line to its stdout, which would
> then go to s6-log to be logged. But I feel a new directive in s6-log
> seems a simpler (and more reliable) solution...
>
Gotcha. I don't think you need awk for this. I'd imagine something
like "s6-log - +eventmatch 1 + /var/log/normallog > /var/log/logfifo"
would correctly output your events to the fifo while sending
everything to the normal log directory. Thinking about this a bit
more, I think that you want is to have the ability to add processors
to arbitraty outputs, as opposed to just as a log-rotation system. If
you had that, the following would be possible:
6-log - +eventmatch 1 !"sed 's/^/mydaemonerror: '" +
/var/log/normallog > /var/log/logfifo
in order to prepend anything going to the fifo with the text 'mydaemonerror:'
As it stands you need: s6-log outputting your matches to independent
fifo A, a log broker service listening to fifo A that prepends text to
that text stream and then pumps the results down shared fifo C, and a
collation service that reads fifo C and writes to an instance of
s6-log that drops stuff into the right place(s). Adding additional
services is simply a case of adding new s6-log's outputting to new
fifos, and new brokers listening to those fifos and routing messages
down fifo c.
The syslog replacement daemon does exactly this by the way: daemons
write to /dev/log, s6-ipcserverd listens and spawns ucspilogd's to
handle decoding the syslog streams, and the output is fed to a s6-log
to either write to a single file or split the output along syslog
channel names. Here ucspilogd takes the place of the mid-stage
listener services, and s6-ipcserverd handles the message routing.
Syslog style logging alread handles adding the channel uniqueness
which allows a single manager to handle all the transformations into
human readble message names. If you could get your daemons to output a
bit of uniqueness at the front of all their messages, you'd be able to
forego N middle-tier log brokers and instead send all messages down
the combined fifo from the get-go.
>
> Cheers,
> -j
>
Apologies for getting a bit rambly. Like I said, it's a sound usecase
that's solvable with some oddness.
--
"If the doors of perception were cleansed every thing would appear to
man as it is, infinite. For man has closed himself up, till he sees
all things thru' narrow chinks of his cavern."
-- William Blake
Received on Thu Feb 26 2015 - 07:48:03 UTC