"Laurent Bercot" <ska-skaware_at_skarnet.org> 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
robust.
> 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.
/Esben
Received on Fri May 26 2023 - 10:25:58 CEST