Buffering delays of log when redirected (was Redirection of log doesn't work on Raspberry Pi)

[MynockSpit]

For some reason, redirection of any kind (so far as I can tell) silences logging.

Example showing that w/o redirection, it prints logs

Example w/ tee

Example with >

[fduncanh]

what are you trying to do?

(the ";" after the & is syntax error, at least in bash)

[MynockSpit]

The bit before and including the semi-colon is just to show that five seconds have passed (echo out after five seconds) before I manually killed the program.

The behavior is the same (no output from uxplay) without that.

(Just noticed that the third example isn’t the right screenshot. I’ll update it shortly.)

I want to record the stdout and stderr from uxplay to a file, but redirection seems to silence it.

[thiccaxe]

Can you test with cat or something instead of uxplay?

[MynockSpit]

Yup. Works fine with echo.

[MynockSpit]

Okay, so I guess it's a bit more complicated. Seems like the output isn't written until after the process has been killed. Is that intentional? And if so, is it possible to change that behavior? I'd like to be able to tail the log as it's running to see what uxplay is doing.

[fduncanh]

The "log" is exactly what you see on the terminal. To see more "uxplay -d"

0. to just watch but not save: (this obviously wont work in a fullscreen mode, when you cant see the terminal) uxplay -d

1. To send it to a file uxplay -d > logfile 2>&1

you wont see the terminal output.

2. to then watch on a different terminal (use ssh to get one if you are using the Pi 5 in "Lite" mode without X)

tail -f logfile

to save and also watch on the uxplay terminal

3. uxplay -d | tee logfile

yes, its jerky (buffered) in case 2 and 3

Maybe without -d there is so little output that the buffer does not drain before you kill the process.

None of this is uxplay-specific.

[fduncanh]

@MynockSpit After the socket is initialized, uxplay is waiting for a client connection. Nothing will be output until a client tries to connect. Your posted images dont seem to show any client activity.

What happens with just

uxplay -d

[MynockSpit]

yes, its jerky (buffered) in case 2 and 3

Ah, so this is what I'm seeing. I'm unused to output being buffered w/ redirections, or at least buffered such large chunks. Is there any way to control the buffer size? I just tested, and it took three songs before it output anything new.

[fduncanh]

@MynockSpit If you think this is a uxplay log issue, it would be an issue in lib/logger,c that controls all logging.

Feel free to identify anything you think could be improved, and submit a PR.

https://github.com/FDH2/UxPlay/blob/master/lib/logger.c https://github.com/FDH2/UxPlay/blob/master/lib/logger.h

• (EDIT) logger_log does all the output, bottom of file logger.c

[MynockSpit]

Just about to post that I think it's just a buffering config thing. This works:

https://serverfault.com/questions/294218/is-there-a-way-to-redirect-output-to-a-file-without-buffering-on-unix-linux

Thanks for the insight!

[fduncanh]

@MynockSpit There was a similar issue in WIndows without redirection that needed

#ifdef _WIN32    /*  use utf-8 terminal output; don't buffer stdout in WIN32 when debug_log = false */
    SetConsoleOutputCP(CP_UTF8);
    if (!debug_log) {
        setbuf(stdout, NULL);
    }
#endif

Does uxplay need anything like this in linux to prevent buffering?

• EDIT: https://www.gnu.org/software/libc/manual/html_node/Controlling-Buffering.html