...what's wrong with writing to stderr? If you do that, then whatever is on its reading side can route the logs wherever and however it wants to, without any need for locking/truncating shenanigans. Or is it way too simple?
Exactly. Nothing at all is wrong with it.
Whereas rotating logs as aforegiven, locked or otherwise, has an unfixable race condition where logs can grow without bounds, because it divorces the log rotater from the log writer. The aforegiven tooling is merely wallpapering over huge cracks and not fixing the actual problems, which were, ironically, fixed with better tooling as long ago as the 1990s.
If you do that, someone who wants to rotate logs can do it by (1) locking the log file, (2) copying it to the rotated file, (3) truncating the log file, and (4) releasing the lock.
Here's a C program, cat-trunc, that does that. Usage is "cat-trunc logfile".
That's a little more complicated than is necessary, because it tries to minimize the time it holds the lock.If you've got a long running program whose stdout you want to log here's a C++ program (but written like it is C plus std::string and std::list because I am lazy), lock-save, to help with that. Usage is "lock-save [-t] file". It copies stdin to file, writing a line at a time, locking the file for those writes. You can then use cat-trunc to rotate the file. The -t option makes it also copy stdin to stdout, making it essentially tee with locks.