Re: new s6-log

From: Laurent Bercot <ska-skaware_at_skarnet.org>
Date: Mon, 09 Feb 2015 00:06:29 +0100

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
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.

-- 
  Laurent
Received on Sun Feb 08 2015 - 23:06:29 UTC

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