After rotation the program must write to the new file. Whether it does depends on how it opens the log.
A program that opens the log for every write — like echo … >> app.log — writes to the new app.log after rotation. But it writes with its own user's rights: if the create line handed the new file to root, the program gets Permission denied.
A program that keeps the log open writes through a file descriptor — to the same file even after the rename, that is, to app.log.1. It is asked to reopen the log by a command in the rule's postrotate block: for nginx in /etc/logrotate.d/nginx it is invoke-rc.d nginx rotate. tail -f holds the file the same way: during a rotation it stays on the renamed file, while tail -F follows the name and moves to the new one. The copytruncate directive copies the log and truncates it instead of renaming, but lines written between the copy and the truncation are lost.
A service keeps its log open the whole time it runs. The rule renamed app.log to app.log.1 and created a new app.log, and it has no postrotate block. Where do the service's next records go?
-
The service writes through an open descriptor, which still points at the old file after the rename. It opens the new
app.logonly when asked to, by a command inpostrotate. -
Renaming neither closes nor deletes the file: writing through the descriptor goes on without errors, just into
app.log.1.
A descriptor is tied to the file itself, not to its name, so the service writes into the renamed app.log.1. It is asked to reopen the log by a command in postrotate, as in the nginx rule.
Key points
- A program that opens the log for every write moves to the new file after rotation, with its own user's rights.
-
A program holding the file open keeps writing to the renamed one; it is asked to reopen the log in
postrotate. -
copytruncatecan lose lines written during rotation.