"Laurent Bercot" <ska-skaware_at_skarnet.org> writes:
>>
>>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.
>
> One of the goals is not to write a partial line if it can be avoided;
> but it defers to the more important goal of not losing any data.
> Your suggestion goes against that more important goal.
I understand. I guess I am questioning the importance of the goal of
not loosing data.
In general, that is a very important goal when handling data. But not
all data is equal.
While adding more options carry it's own burden, it might be worth
considering some kind of option configuring s6-log to do what is best
if loosing data is not of the highest importance.
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.
>
> Nope. Not happening.
>
> Certainly, on shutdown, it doesn't matter whether you get that last
> log line or not. But loggers don't only get killed on shutdown.
Good point.
> There are other, good, reasons why you would want to kill (and
> restart) an s6-log process, and not losing any data is important in
> these cases.
Any chance that this could be handled by handling SIGHUP and SIGTERM
differently?
Thinking out loud... Keep the current behavior of SIGTERM, but change
SIGHUP to throw away a partial line in buffer.
System integraters can then play with the use of SIGHUP and SIGTERM to
get the desired effect. With s6-rc, you can then configure down-signal
to use SIGHUP instead of SIGTERM if you want to get out quickly.
Or you can use timeout-kill to ensure you don't hang around forever if
you stay with SIGTERM.
While that would make s6-log nicer to integrate with s6-rc, I still
think that the current behavior of potentially blocking SIGTERM forever
is undesirable, so some kind of timeout in s6-log could still be a good
idea.
/Esben
Received on Fri May 26 2023 - 11:26:57 CEST