Laurent,
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
administration
> (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
signal,
but EOF has not yet been detected?
Earl
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