Files

T

jochen 2e082d1680 logrotate: rotation on every machine, its base configuration owned

Rotation ran on one machine of four; the others carried package and fail2ban
rules nothing read, and one log had reached 4.9 GB. The module installs
logrotate, owns /etc/logrotate.conf whole (the distribution's base plus
compress/delaycompress, dropping a hand-set olddir that collides same-named
logs) and enables logrotate.timer. Seven tools from a Go bundle, the journal's
usage and vacuum among them (to-be 42 Phase 1).

2026-10-04 12:50:20 +02:00

2.7 KiB

Raw Blame History

logrotate

Log rotation on every machine (novox/hq to-be 42 Phase 1, research 027).

What it owns

The logrotate package.
/etc/logrotate.conf, written whole. It is the distribution's base (weekly, four kept, create, the .pac* taboo, include /etc/logrotate.d, the wtmp/btmp rules) plus compress and delaycompress. A rotated log is compressed one rotation late, so a program still writing to the file it had open loses nothing. The manifest test dry-runs it with logrotate -d where logrotate is installed. The host keeps the machine's previous file once.
logrotate.timer, running and enabled: daily, catching up after downtime.

What it improves

Rotation ran on one machine of four. The other three had rules in /etc/logrotate.d, put there by their packages (nginx, postgresql, samba, cups) and by the mesh's own fail2ban module, and nothing that read them. On the anchor, a web server's access log had reached 4.9 GB and the intrusion prevention log 239 MB.
Rotated logs are compressed everywhere.
The one machine that did rotate had olddir /var/log/archive set by hand. That flattens logs from different directories into one, where two logs with the same name collide. It is dropped. /var/log/archive and what is in it are left as found.

What it leaves found

Every file in /etc/logrotate.d. They belong to their packages and modules.
The journal's own bounds (journald.conf). journald runs on its defaults everywhere: 10 % of the filesystem, capped at 4 GB. The journal tools below read and vacuum it.

Tools

tool		answers
`logrotate_status`	r	each log's last rotation (the status file, through sudo -n), the timer, and the last run; "never run" where it has not
`logrotate_configs`	r	the base's global settings, and each rule file with the logs it rotates
`logrotate_check`	r	`logrotate -d` on the whole configuration: errors and warnings, changing nothing
`logrotate_big_logs`	r	the largest files under `/var/log`, with the total and the journal's share; journal files listed on request
`logrotate_force`	a	`logrotate -f -v` on one rule file, with the base's globals in front so it rotates as the nightly run would, or on every log
`logrotate_journal_usage`	r	`journalctl --disk-usage` and the journald settings that bound it
`logrotate_journal_vacuum`	a	`journalctl --vacuum-size/--vacuum-time`, with what each directory freed

Forcing one rule file alone would leave out what the base sets. A rule that names no count would then keep no old logs at all. So the tool writes the base's globals to a file that root owns, which is the only kind logrotate running as root will read, and passes it in front of the rule.

2.7 KiB Raw Blame History