Is Logrotate Working? Check Scheduling, Rotation and the Active Log

A growing log sits beside several .gz archives. That does not establish that logrotate worked today. Those archives could be old, and the application might still be writing into a file that has already been rotated.

Log rotation moves an active log into an archive and arranges for new messages to reach a current file. Logrotate manages timing, retention and compression. Diagnose three separate questions: did the scheduler run, was the file eligible for rotation, and did the application switch to the new file?

Inspect the schedule before forcing a run

Many systemd distributions invoke logrotate through a timer. The timer determines when to trigger the task; the service executes it. Look at the previous run and its result first:

systemctl list-timers --all logrotate.timer
systemctl status logrotate.timer logrotate.service --no-pager
sudo journalctl -u logrotate.service --since "2 days ago" --no-pager

A one-shot service can appear inactive after completing successfully. Read its last exit result and the next timer event rather than treating that state alone as a fault. An installation without the timer may use cron. Inspect its /etc/cron.daily/ jobs and cron configuration; package layouts differ between distributions.

logrotate -f is not a harmless inspection command. It can perform real rotation before normal eligibility, remove archives under the configured policy and execute service hooks. Start with a mode that does not change files.

Read the full configuration in debug mode

sudo logrotate --debug /etc/logrotate.conf

--debug reports decisions without changing logs or the state file. Look for the reason a file is skipped, the rules being read and configuration errors. Testing only an application's small configuration file may omit defaults inherited from the main file. Compare your test with the command the scheduled service actually runs.

The state file records prior rotation activity. Its path depends on packaging and invocation, so use the installed manual and service definition rather than assuming one universal location. The recorded state should explain the debug decision. Deleting that file changes later scheduling decisions; it does not diagnose the original problem.

A daily rule does not wake up the program

daily makes logrotate evaluate daily eligibility when it runs. The rule cannot start the program itself. Likewise, crossing a maxsize threshold does not trigger an immediate background event. The threshold is checked at the next invocation. A rapidly growing file may need a more frequent schedule as well as an appropriate size policy.

size and time-based rules such as daily are not interchangeable, and their ordering matters. If you need daily rotation with an additional opportunity to rotate an oversized file earlier, inspect maxsize. minsize instead adds a minimum size requirement to time-based eligibility. The logrotate manual describes those distinctions.

Check which file receives new messages

Renaming a file does not change an application's open file descriptor. It can continue writing to the old file. Find the application's documented mechanism for reopening logs; that is often what a postrotate hook needs to call. Do not copy a service-specific signal command into another application's configuration.

Replace the sample uygulama directory below with your log directory. ls -li includes inode numbers, which identify files within a filesystem:

sudo ls -li /var/log/uygulama/
sudo lsof /var/log/uygulama/app.log
sudo lsof +L1

The final command lists open files with no remaining filesystem links; output can be extensive on a busy system. If the new log stays empty while the old one grows, revisit the reopen step. Deleting the active file can produce the deleted-but-open log problem rather than freeing its space.

copytruncate is sometimes used when an application cannot reopen its log: logrotate copies the content and truncates the existing file. Data written between those operations can be lost. Treat that trade-off explicitly when the records matter for incident investigation. When using create, the new file's owner and permissions must also permit the application to write.

Follow the next real rotation

After correcting the configuration, repeat the debug check. Following a scheduled or deliberately planned real run, verify that the service succeeded, the expected archive exists and the current log grows with new requests. The appearance of a .1 file alone does not establish all three.

If the space is actually consumed by systemd-journald, changing plain-file logrotate rules will not manage that storage. Journal retention has its own settings. Identify the growing source first, then verify the rotation or retention behavior responsible for that source.