Re: new s6-log

From: Olivier Brunel <jjk_at_jjacky.com>
Date: Tue, 10 Feb 2015 01:25:06 +0100

On 02/09/15 00:06, Laurent Bercot wrote:
> On 08/02/2015 22:12, Olivier Brunel wrote:
>> Except for that bit. I don't like that, and I'd really like an option to
>> turn that behavior off. Specifically, in my case the only scenario I can
>> imagine where the write would fail, i.e. daemon is down, would be
>> because it crashed/was restarted; Neither of which should mean to stop
>> the whole process.
>
> It's a question of safety. Imagine the daemon dies and never comes
> back up. Should I let lines accumulate indefinitely in s6-log's bufalloc_1,
> eating more and more memory until the inevitable oom ? Definitely not.
> Then what ? Any other solution loses log lines.
>
> Plus, a write error likely means that the pipe between s6-log and the
> auxiliary logger is broken. It can never be used again. It's impossible
> to resume writing to another instance of the auxiliary daemon without
> restarting s6-log. So, why keep stuff in a buffer that can probably never

Well, I may have mixed up memories of the idea of s6-log using a file vs
simply stdout, as in with a file it could simply (re)open it, no need to
restart then actually (and since I'm actually gonna use a fifo, that'd
have worked). Anyhows...

> be flushed again ? If you need that auxiliary logger, you have to restart
> the pipeline. Kill your entire logging service, which will recreate the
> pipe.
>
> You can avoid killing s6-log by fd-holding the reading end of the pipe:
> have some other process keep it open. That's easy to do if you're
> supervising the auxiliary logger. And in that case, s6-log will never
> receive an EPIPE, it will just detect non-readability, and keep the
> log lines in memory until your auxiliary logger has restarted. That is
> the way to obtain the behaviour you want.

Yes, I think I spoke too quick and was silly/wrong as a result. But
you're right, and this will work fine; I just played a bit with the
fdholding tools, seems to work very nicely/easily. :)

Quick question though, in case I missed something obvious: what did you
have in mind when you said: "[keeping the fd open is] easy to do if
you're supervising the auxiliary logger" ?

In my case I'm using a fifo (between s6-logs & the auxiliary logger), so
I just open it and store it to a fdholderd prior, and the auxiliary
logger retrieves it on start. Is there another/a better way to do this?
(because I'm not sure how the fact that it's supervised helps/changes
anything?)
Or were you thinking of another situation/configuration?
Received on Tue Feb 10 2015 - 00:25:06 UTC