Re: s6 problems logging

From: Guillermo <gdiazhartusch_at_gmail.com>
Date: Sun, 27 Jan 2019 16:35:48 -0300

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.
Received on Sun Jan 27 2019 - 19:35:48 UTC