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
