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

From: Colin Booth <cathexis_at_gmail.com>
Date: Tue, 28 Jul 2015 18:33:19 -0700

On Jul 28, 2015 5:42 PM, "Laurent Bercot" <ska-supervision_at_skarnet.org>
wrote:
>
> On 28/07/2015 17:58, Colin Booth wrote:
>>
>> 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'll +1 Wayne: this is in no way guaranteed. It's only true for
> s6-log if there's only one logdir, and up to the first rotation. It
> changes for every rotation - often, but not always, oscillating
> between 4 and 6.
Huh, I watched it through a few rotations and it never moved off of fd 4 (a
host of mine has some brutal clock skew and has been slowly ntp-slewing
it's way back into line). I didn't look at s6-log processes servicing
multiple logdirs, those are definitely going to skew things. Which means
I'm probably wrong vis-a-vis svlogd and fd 6 as well.
>
> If you want to go the "map the current log file" route instead of
> the "insert hooks somewhere in the log flow" one, grepping all the
> links in /proc/$loggerpid/fd for /current$ sounds like a better
> solution - and even then it's still hackish.
It's hacky, but at least it's accurate and not as race-prone as reading
data out of the log script itself. A heavy-weight solution like inserting a
data-forking service in the logging chain is cleaner but another step in
the logging chain than could fail and take out everything. One of the nice
parts of the daemontools/s6 logging guarantee is that your logger is
guaranteed to get it's messages. Adding a log fork-and-forward service is
another point of failure.
>
Cheers!
-Colin
Received on Wed Jul 29 2015 - 01:33:19 UTC