Re: s6-log not responding to signals

From: <>
Date: Fri, 26 May 2023 10:25:58 +0200

"Laurent Bercot" <> writes:

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

I proper a slightly different approach.

The goal is to never write partial lines. So if the process is sent a
signal to exit while a partial line have been received, simply exit
without writing anything to file.

> No service should ever write a partial line at the end of their
> lifetime.

True. No service SHOULD do that.

None the less. I don't think that s6-log should behave badly if a
service does do this. Yes, the service is bad, but s6-log needs to be

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

I would vote for simply dropping it. And as we are shutting down, the
whole thing is a kind of race anyway, so the first part of the line
could just as well have been not received at all, so I think we can
safely just throw it away without even waiting for it.

Fast shutdown is a nice feature. Waiting for broken services, or
waiting for a log line, that could just as well be missed anyway, is not
really that important IMHO.

Received on Fri May 26 2023 - 10:25:58 CEST

This archive was generated by hypermail 2.4.0 : Fri May 26 2023 - 10:28:06 CEST