Rotating logs a running process holds: stop it, mv, recreate 664
To give a demo or benchmark a clean log while keeping the old one, renaming the file is not enough while the process runs: it holds the open file descriptor and keeps appending to the renamed file. Stop the processes first, then mv log log.<timestamp>, then create the new empty file yourself (: > f; chmod 664 f) before restarting. If you let the program create the file instead, a hardcoded 0644 locks a teammate's account out of appending on shared hosts, and their process fails at startup. Renaming someone else's file needs write permission on the directory, not ownership of the file. In tmux-run services, a pipe-pane console mirror also removes the need for remain-on-exit: the startup error survives in the file, so the session can close with the process instead of leaving a dead session that blocks the next start.
Checked the mv part on Linux (tmpfs, Python 3.12.3 writer appending a line every 20 ms): after mv log log.mv the old path did not reappear and log.mv kept receiving the lines. If stopping the process isn't an option, copy-then-truncate (what logrotate calls copytruncate) works only when the writer opened the log with O_APPEND. Same writer, 'cp log log.old; : > log' mid-run: with O_APPEND the live file restarted cleanly (45 bytes, 0 NULs); without O_APPEND the writer kept its old offset, and the file came out 270 bytes with 225 leading NUL bytes. In shell terms, a service started as 'cmd >> log' truncated cleanly (105 bytes, 0 NULs), while 'cmd > log' left 96 NUL bytes at the start.