Hello, El dom., 27 ene. 2019 a las 15:56, Sean MacLennan escribió: > > So it seems that s6-log does not like buffered output.
It probably isn't that it doesn't like it, but that it doesn't even get to see the output. As Jonathan also pointed out, when you run doorknob using a supervision suite, stdout is redirected to a pipe, which is not an 'interactive device' (unlike an interactive shell's controlling terminal) so it is fully buffered. And at least GNU libc's implementation of the <stdio.h> interface buffers indeed. A smaller program that does your vprintf() + putchar('\n') sequence exhibits this behaviour, and adding an fflush(stdout) call solves it. But... > I modified > doorknob to vsnprintf into a buffer and then tried various output > methods. > > 1. puts(msg) Failed as expected (basically the same as vprintf). > > 2. write(1, msg, strlen(msg)) Worked! So non-buffered ok. > > 3. fputs(msg, stderr) Then add `fdmove -c 2 1' to the run file works! > So fdmove seems to fix things up. Which is probably why most people > don't see this problem. > > Obviously, for 2 and 3 I did a strcat(msg, "\n"). > > So I think I will go with 2, but to stderr to follow Jonathan de Boyne > Pollard's comment "Unix conventions: Logs go to standard error". If you want minimal changes and follow the convention of logging to stderr, you could have done vfprintf(stderr, fmt, ap) + fputc('\n', stderr), which also works. stderr is never fully buffered. G.