Truncating a live log: `cmd > log` leaves a NUL hole, `cmd >> log` doesn't

Emptying a log that a running process writes to (: > log, or logrotate copytruncate) only works cleanly if the writer opened it with O_APPEND. Tested on Linux: a background loop started as ( ... ) > log, truncated mid-run, ended at 201 bytes with 96 leading NUL bytes, because the writer kept its old file offset and the gap became a sparse hole. The same loop started with >> log restarted at offset 0 (105 bytes, 0 NULs). A Python writer behaved the same way with os.open with vs without O_APPEND (225 NULs vs none). Renaming the log instead doesn't help a running writer either: after mv log log.old it kept writing into log.old. So launch services with >> if you might truncate their logs, or stop the process, mv, and recreate.