Re: Working on shell for perp/s6/etc., need advice re logging

From: Ido Perlmuter <ido_at_ido50.net>
Date: Tue, 28 Jul 2015 19:57:22 +0300

Thanks for the suggestions guys.

You're not going to be able to get a separate view of stdout and
> stderr since you've redirected those to the same place. As long as
> that isn't an issue it should be pretty easy to solve this the right
> way instead of using strace, funky interstitial logging scripts,
> parsing the log script, etc. Assuming you're on linux and the output
> file descriptor is stable, "the right way" is to use procfs to
> directly read against the file descriptor that the logger is
> outputting to. I don't know which file descriptors tinylog uses but
> s6-log uses fd 4 for its file.
>

I forgot to mention that I have no interest in a separate view of the
channels, so that's fine. I've made a quick check with perp and it is using
fd 4 as well.


>
> The below is for s6-log, something similar is doable with perp:
> Use s6-svstat to find out the logger pid, parse the output for the
> process id, then readlink /proc/$loggerpid/fd/4 to get the logger
> output location (or, if you're feeling lazy, just tail the fd
> directly). Caveats: you'll need account access to read
> $svcdir/$svc/log/supervise as well as /proc/$pid/fd, and the current
> fd 4 will stop being useful when a file rotation happens.
>

Cool, this works.


> I'd say write the management compatibility layer (which it sounds like
> you already have), and then use the energy you'd spend fighting unix
> pipes on teaching people how to make the most out of perp.
>

I suppose enforcing a certain logging policy for anyone whishing to use my
shell is somewhat unavoidable, but I'll keep looking into those options to
see what I can do to be as unobtrusive as possible. Though your suggestion
was meant to avoid that, I *could* try to read the rc.log (/log/run)
scripts to check which logger is being used (with a simple search of
tinylog, s6-log, svlogd, etc.) in order to know which fd I need.


> [0] Most of the services at work don't log anything locally and
> instead send data down a zmq socket to N log brokers that forward
> along to their subscribers. It's pretty heavy-weight, really slick,
> and mostly functional.


That's cool, never heard of ZeroMQ being used for logging, this is
something to examine regardless of this exercise.

Thanks again,
Ido.
Received on Tue Jul 28 2015 - 16:57:22 UTC