Re: s6-log not responding to signals

From: Earl Chew <>
Date: Fri, 26 May 2023 06:59:05 +0200


How are you thinking changes to termination behaviour will interact with
the existing -p option?

> -p : protect against SIGTERM. Do not exit on receipt of a SIGTERM;
> only exit on a SIGHUP or when reading EOF on stdin. This is useful for a
> logger that you really do not want to lose even if automated
> (e.g. the downing of a supervision tree) would kill it.

As suggested by the documentation, when s6-log is waiting for a newline
to arrive,
its behaviour could be influenced by a) EOF on stdin, b) termination signal.

Are you thinking of adding the timeout only if there is a termination
but EOF has not yet been detected?


On Thursday, May 25, 2023, 16:20, Laurent Bercot wrote:
>> The problem is that until a new-line is received, s6-log will not
>> respond to SIGHUP and SIGTERM.  I assume this is not as expected.
>  This is expected; the goal is to finish reading partial lines
> before existing. This is useful with services that are writing a
> large amount of logs, where the buffer length does not necessarily
> align with a newline: after receiving the signal, the logger reads
> until the next newline, processes the line, then exits.
>  No service should ever write a partial line at the end of their
> lifetime.
>  However, I agree that the situation you're describing is not ideal
> and s6-log should be more robust. I'm thinking of adding a timeout:
> if s6-log hasn't received the end of a partial line n milliseconds
> after receiving a terminating signal, then it should process the
> partial line anyway and exit. What do you think?
> --
>  Laurent
Received on Fri May 26 2023 - 06:59:05 CEST

This archive was generated by hypermail 2.4.0 : Fri May 26 2023 - 06:59:47 CEST