Mastering Linux Log Management with crontab and logrotate

Log Management Goals

Effective log management consists of two main parts: (1) designing appropriate log content—such as anchors, formats, and levels—to aid troubleshooting and audit trails, and (2) defining archiving policies, including rotation methods (by date, size, etc.) and retention limits (e.g., keep only the last month).

For custom‑built services, developers can configure logging frameworks like Logback or Log4j. However, third‑party components (MySQL, nginx, Redis, Nacos, Sentinel, etc.) often lack flexible log settings, making external management necessary.

Special Log Scenarios

Applications started with nohup without proper redirection keep writing to nohup.out or a single file.

MySQL can specify a log file path but does not auto‑clean old logs.

nginx allows custom log formats and paths (default access.log, error.log) but also lacks automatic cleanup.

In these cases logs grow indefinitely, eventually exhausting disk space and causing system failures.

Tool – Scheduled Cleanup with crontab

Linux’s built‑in scheduler crontab can run a cleanup script periodically. Example to keep only the most recent 7 days:

crontab -e</code><code># Delete logs older than 7 days</code><code>1 0 * * * find /logs.dir/ -mtime +7 | xargs rm -rf

Common Pitfalls When Managing Open Log Files

Renaming a log file while the service keeps writing to the original file leaves the old file active.

Deleting a log file (e.g., rm -f) requires restarting the service; otherwise the file handle remains and disk space is not freed.

Deleted but still‑open files are invisible to ls and du, yet df shows the real usage; lsof must be used to locate them.

Practical Remedies

For one‑time cleanup, truncate the file (e.g., echo > log.log) instead of removing it.

If a file has already been removed, identify the holding process with lsof | grep -i deleted and restart that process.

To retain log data while limiting size, use logrotate with a copy‑and‑truncate strategy: copy the current log to an archive and then truncate the original file.

Tool – logrotate

logrotate

is a Linux utility that integrates with cron to rotate, compress, and manage log files according to user‑defined rules. It cannot alter the content generated by applications but can control file lifecycle.

Key Parameters

Rotation period (daily, weekly, monthly)

File extensions

Rotation method (copytruncate, create, delete)

Compression (compress, delaycompress, nocompress)

Retention count (rotate N)

logrotate [OPTION...] <configfile></code><code>-d, --debug      # test configuration</code><code>-f, --force      # force rotation</code><code>-m, --mail=cmd  # mail rotated logs</code><code>-s, --state=file # custom state file</code><code>-v, --verbose   # verbose output

Example nginx configuration ( /etc/logrotate.d/nginx):

/usr/share/nginx/log/*.log{</code><code>    daily</code><code>    missingok</code><code>    rotate 7</code><code>    compress</code><code>    delaycompress</code><code>    notifempty</code><code>    create 644 root root</code><code>    sharedscripts</code><code>    postrotate</code><code>        [ ! -f /var/run/nginx.pid ] || kill -USR1 `cat /var/run/nginx.pid`</code><code>    endscript</code><code>}

Schedule it via cron:

echo "0 0 * * * /usr/sbin/logrotate -vf /etc/logrotate.d/nginx > /dev/null 2>&1" >> /var/spool/cron/root

Parameter Details

compress

– gzip the rotated file. nocompress – keep it uncompressed. copytruncate – copy the log then truncate the original (useful for files still open). nocopytruncate – copy without truncating. create mode owner group – create a new file with specified permissions. nocreate – do not create a new file. delaycompress – compress on the next rotation. nodelaycompress – compress immediately. missingok – ignore missing files. notifempty – skip rotation if the file is empty. mail address – email the rotated log. olddir directory – move rotated logs to a specific directory. sharedscripts – run postrotate script once for all logs. prerotate / postrotate – commands executed before/after rotation. size / minsize – rotate when the file reaches a given size (e.g., size 100M).

Appendix: Simple logrotate Configurations

# MySQL logs</code><code>/data/mysql/log/mysqld.log{</code><code>    daily</code><code>    dateext</code><code>    dateyesterday</code><code>    copytruncate</code><code>    notifempty</code><code>    missingok</code><code>    olddir backup</code><code>    rotate 60</code><code>    compress</code><code>}</code><code></code><code># nginx logs</code><code>/usr/local/nginx/logs/access.log</code><code>/usr/local/nginx/logs/error.log{</code><code>    daily</code><code>    dateext</code><code>    dateyesterday</code><code>    copytruncate</code><code>    notifempty</code><code>    missingok</code><code>    olddir backup</code><code>    rotate 30</code><code>    compress</code><code>}

Component‑Specific Log Management Summary

nginx – no built‑in cleanup; logs grow continuously.

MySQL – same limitation as nginx.

Zookeeper – supports automatic cleanup via size/count limits in its Log4j configuration.

Redis – logs are minimal and usually do not require rotation.

Kafka data logs – automatic cleanup enabled; configuration handled in Kafka settings.

Kafka operation logs – stored under logs/, support rotation but not automatic deletion; managed via Log4j.