logrotate Config Generator

Fill in the fields and get a complete, correctly formatted /etc/logrotate.d/ stanza — frequency, retention, compression, permissions and an optional postrotate block.

logrotate does not run continuously in the background — it is invoked periodically, almost always by /etc/cron.daily/logrotate or a systemd timer of the same name, and each run checks every stanza under /etc/logrotate.d/ to see whether that file’s condition (a time interval, or a size threshold) has been met. A stanza with weekly does not rotate on some rolling seven-day clock; it rotates on the next logrotate run after the recorded last-rotation date has aged past a week, which is why rotations can drift by hours depending on when cron actually fires.

The order of directives inside the brace block does not matter to logrotate, but its interpretation of compress and delaycompress together is worth understanding precisely: delaycompress does not delay compression by some fixed time, it specifically leaves the most recently rotated log uncompressed until the next rotation cycle. That exists because many applications keep writing to the old file handle briefly after rotation, until they notice the file moved and reopen it — compressing immediately can truncate or corrupt output written during that window. Without delaycompress, that race is real; with it, the previous log stays plain text for one extra cycle and only the older ones get compressed.

copytruncate and a postrotate reload signal solve the same underlying problem — a process holding a now-renamed file open — in opposite ways, and combining both is redundant at best. copytruncate copies the current log’s contents to the rotated filename, then truncates the original in place, so the application’s open file descriptor is never invalidated and it never needs to be told anything happened. The tradeoff is a small window between the copy and the truncate where log lines can be lost, and it is meaningfully slower on large files since the whole file gets copied. Where you can signal the application to reopen its log file cleanly — most daemons support this via SIGHUP or an equivalent reload command — that is the better option and is what this tool defaults to.

sharedscripts matters specifically when the log path is a glob matching multiple files. Without it, logrotate runs the postrotate block once per matched file that actually got rotated, which for a reload command means restarting the same service several times in a row for no benefit. With sharedscripts, the block runs exactly once after all matching files in the stanza have been processed, which is almost always what you actually want when the postrotate script reloads a shared service rather than acting on an individual file.

create and copytruncate are mutually exclusive in effect, if not enforced by logrotate itself: create makes logrotate create a fresh empty file with the specified mode, owner and group immediately after moving the old one aside, which only makes sense when the application will reopen or recreate the file itself. copytruncate never removes the original file at all, so there is no new file for create‘s permissions to apply to. Setting explicit permissions matters most when the log-writing process runs as a different user than the one that would otherwise own a file logrotate creates by default — a common gap that leaves a freshly rotated log unreadable by the monitoring agent that expects to tail it.