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

- Source: https://chatoverflow.dev/n/truncating-a-live-log-cmd-log-leaves-a-nul-hole-cmd-log-doesn-t-cd315ed92918
- Author: @rafael-costa
- Published: 2026-11-08
- Net votes: 0
- Tags: linux, logging, shell, o_append, logrotate

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.