Logrotate Config Generator

Build a logrotate configuration block without memorising directive names. Point it at a log path, choose how often to rotate and how many old files to keep, toggle compression, a size trigger, dateext naming and the create vs copytruncate strategy, and add prerotate/postrotate commands. The matching config block is generated live, ready to drop into /etc/logrotate.d/. Everything runs in your browser.

How to use the Logrotate Config Generator

Enter the log path or glob you want managed — a single file like /var/log/myapp.log or a pattern like /var/log/myapp/*.log. Pick a rotation frequency and how many rotated files to keep; optionally add a size trigger so a fast-growing log rotates before its scheduled time. The checkboxes map directly to logrotate directives: compress with delaycompress keeps the most recent rotation uncompressed (handy for tools still tailing it), dateext names rotations by date instead of a numeric suffix, and missingok/notifempty avoid errors and pointless empty rotations.

The file handling choice is the one to get right. create renames the live file and opens a fresh one with the mode and owner you specify — correct for most daemons that hold the path. copytruncate copies then truncates in place, which suits processes that keep the file descriptor open and won't reopen on signal, at the cost of a tiny window where lines can be lost. Add postrotate commands (for example a reload signal) when your service needs to reopen its log; with sharedscripts the script runs once for the whole glob rather than once per file. Copy the generated block into a file under /etc/logrotate.d/ and test it with logrotate -d (debug, no changes) before relying on it.

What logrotate does and why the directives matter

logrotate is the standard Linux utility for keeping log files from growing without bound. Run from cron or a systemd timer, it reads configuration from /etc/logrotate.conf and the drop-in files in /etc/logrotate.d/, and for each managed path it decides whether to rotate — rename the current file aside, optionally compress old ones, delete those past the retention limit, and let the application start writing to a fresh file. It is deliberately declarative: you describe the policy and logrotate enforces it on every run.

Most production incidents with logs come down to two directives. The first is the create vs copytruncate decision: a program that opens its log once and writes to that file descriptor will keep writing to the renamed file unless it is told to reopen — which is why create is usually paired with a postrotate reload, while copytruncate exists for programs that can't reopen. The second is compression timing: delaycompress leaves the newest rotation uncompressed so a process that hasn't yet reopened doesn't write into a gzip file. Getting these right is the difference between clean rotation and silently lost or corrupted logs.

Retention is the other half of the policy. rotate N sets how many old files to keep, frequency sets the cadence, and a size or maxsize trigger lets a burst of logging force an early rotation so a single file never fills the disk. Because the configuration is just text, the safe workflow is to generate a block, drop it in /etc/logrotate.d/, and dry-run it with logrotate -d /etc/logrotate.conf, which prints exactly what would happen without touching anything. This generator produces a conventional, well-formed block covering those directives so you can start from something correct and adjust.

Common use cases

  • Application logs. Rotate a daemon's logs daily with compression and a reload signal so it reopens cleanly.
  • High-volume services. Add a size trigger so a noisy log rotates before it can fill the partition.
  • Legacy processes. Use copytruncate for software that holds the file open and can't reopen on signal.
  • Disk-space hygiene. Cap retention with rotate N and compression to bound how much log history is stored.

Frequently asked questions

When should I use copytruncate instead of create?
Use create (the default style) when your program can reopen its log file — typically after a reload signal in postrotate. Use copytruncate only for software that keeps the log file descriptor open and cannot be told to reopen; it copies the file then truncates the original in place, which avoids losing the file handle but leaves a brief window where log lines written during the copy can be lost.

What does delaycompress do?
It postpones compression by one rotation, so the most recently rotated file stays uncompressed until the next cycle. This matters when a process has not yet reopened the file after rotation: without delaycompress it could keep writing into what is now a gzip file. It is commonly paired with compress.

How do I test the configuration safely?
Run logrotate in debug mode: "logrotate -d /etc/logrotate.conf". This parses your config and prints what it would do without rotating anything or running scripts. To force a real run for testing, use "logrotate -f". Always dry-run first when adding a new block.

Where do I put the generated block?
Save it as a file under /etc/logrotate.d/ named after your application (for example /etc/logrotate.d/myapp). Files there are included automatically by the main /etc/logrotate.conf. Keep one file per application for clarity.

Does the size trigger replace the frequency?
No — they combine. With both a frequency (such as daily) and a size, logrotate rotates on the schedule and also rotates early if the file exceeds the size between scheduled runs. Use maxsize for size-or-schedule semantics and size for size-only in older versions; this tool emits the size directive alongside the frequency.