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

From: Ido Perlmuter <>
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,
Received on Tue Jul 28 2015 - 16:57:22 UTC

This archive was generated by hypermail 2.3.0 : Sun May 09 2021 - 19:44:19 UTC