"Laurent Bercot" <[email protected]> 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
