Introduction

Deleting old logs safely is usually a retention problem, not a raw delete problem. The goal is to keep enough history for debugging, auditing, and compliance while preventing logs from filling the disk. The standard solution is log rotation with age or count limits, not ad hoc rm commands scattered across cron jobs.

Decide the Retention Policy First

Before configuring anything, answer these questions:

• how many days of logs do you need?
• should rotated logs be compressed?
• do logs need to be archived elsewhere before deletion?
• does the application reopen log files automatically, or must it be signaled?

That policy determines whether you keep 7 daily files, 30 days, or perhaps several compressed archives.

If you skip this step, you risk either deleting useful incident data too early or keeping so much history that the disk still fills up.

Use logrotate on Linux

On Linux, logrotate is usually the right default. It can rotate by time or size, compress old logs, and delete them after a chosen number of rotations.

Example configuration:

1/var/log/myapp/*.log {
2    daily
3    rotate 14
4    compress
5    missingok
6    notifempty
7    create 0640 myapp myapp
8    postrotate
9        systemctl reload myapp >/dev/null 2>&1 || true
10    endscript
11}

What this does:

• rotate logs daily
• keep 14 old rotations
• gzip old files
• skip missing or empty logs
• create a fresh log file with the right ownership
• reload the app after rotation if needed

This is much safer than deleting active log files directly.

Test Before You Rely on It

Do not assume a rotation config is correct just because it looks reasonable. Test it.

logrotate -d /etc/logrotate.conf

The debug mode shows what logrotate would do without changing files. That is the fastest way to catch path mistakes and bad assumptions before they hit production.

When a Simple Cleanup Script Is Enough

Some environments do not use logrotate. For example, a custom app may write disposable export logs to one directory, and all you need is age-based cleanup.

In that case, a scheduled find command can be acceptable.

find /var/log/myapp -type f -name '*.log' -mtime +30 -delete

This deletes .log files older than 30 days.

Use this approach only when you are sure the files are not active logs still held open by a running process. Deleting an active file can produce confusing behavior because the process may continue writing to an unlinked inode.

Application-Level Rotation Matters Too

Many applications already support their own retention settings. Java logging frameworks, Nginx, databases, and container runtimes may rotate logs internally. If you stack external deletion on top of app-managed rotation without understanding both layers, you can end up double-rotating or deleting files unexpectedly.

The clean approach is:

• use the application's built-in retention if it is robust enough
• otherwise use one external rotation strategy consistently
• avoid two independent retention systems fighting each other

Containers Need Special Care

In containers, logs may not even live in ordinary app-managed files. They may go to standard output and be handled by the container runtime or orchestration platform instead.

That means the correct deletion setup may live in Docker or Kubernetes logging policy rather than inside the container filesystem. If you are in a containerized environment, check where logs are actually written before configuring retention.

Common Pitfalls

The biggest mistake is deleting active log files directly without using rotation or application-aware signaling.

Another mistake is keeping no compressed history at all, then losing the only useful traces right after an incident.

A third issue is combining multiple retention mechanisms without a clear owner, such as app-level rotation plus logrotate plus a cleanup cron job.

Summary

• Set a retention policy before choosing the deletion mechanism
• On Linux, logrotate is usually the safest default for rotating and deleting old logs
• Test rotation rules with debug mode before relying on them
• A find ... -delete script is acceptable only for inactive or disposable log files
• In containers and modern platforms, verify whether logging is handled by the runtime instead of local files