Linux定时清理日志脚本文件夹

约 10 分钟读完 0 阅
文章导读
搜「Linux定时清理日志脚本文件」的人，通常卡在同一处：知道要删旧日志，但不确定脚本该写成什么样、该放在哪个目录、定时任务该填哪条路径、以及怎么确认它真的按预期跑过。可以直接照着做的最小路径是：把清理脚本放到 /usr/local/sbin/ 下，用 find 按修改时间删除文件，用 crontab 每天定时调用，跑完查 /var/log/ 下的执行日志和 find 的删除结果。前提是先确认哪些
📋 目录
  1. 壹 Linux定时清理日志脚本文件怎么写
  2. 贰 Linux定时清理日志脚本文件在哪里
  3. 叁 定时清理日志脚本文件：先把能核对的事实摆清楚
  4. 肆 定时清理日志脚本文件最容易搞错的一点
  5. 伍 定时清理日志脚本文件：一个照着就能做完的做法
A A

搜「Linux定时清理日志脚本文件」的人，通常卡在同一处：知道要删旧日志，但不确定脚本该写成什么样、该放在哪个目录、定时任务该填哪条路径、以及怎么确认它真的按预期跑过。可以直接照着做的最小路径是：把清理脚本放到 /usr/local/sbin/ 下，用 find 按修改时间删除文件，用 crontab 每天定时调用，跑完查 /var/log/ 下的执行日志和 find 的删除结果。前提是先确认哪些日志被人为轮转、哪些被进程持续占用；正在被写入的文件不要交给一次性删除脚本处理。

处理这类需求的顺序是：先定位日志实际目录和文件命名规律，再写按 -mtime 判断的删除脚本，最后挂到 crontab 并用执行日志核对。适用范围是没有接入 logrotate 或不想改 logrotate 配置的简单场景；已有 logrotate 的主机，优先在 /etc/logrotate.d/ 里调整，而不是再叠一层删除脚本。验证方式看脚本自身输出日志与目标目录文件数量变化；风险边界是递归删除、误匹配目录、删到被进程持有的文件导致空间不释放。

Linux定时清理日志脚本文件怎么写

「怎么写」对应的是整套动作里的第二步：已经知道哪个目录堆积了日志，现在要把删除规则固化成脚本。确认是不是卡在这一步，看两点：你是不是还在手工执行 rm，以及你能否说清要删文件的判断条件（按修改时间、按文件名后缀、按大小）。说不清条件，就还没到写脚本阶段，得先回去看目录。

脚本通常放在 /usr/local/sbin/，这个位置不在普通用户 PATH 里，避免误执行；名字建议带明确含义，例如 clean-app-logs.sh。下面这段可以直接复制后改路径使用：

#!/bin/bash
# 用途：清理指定目录下超过 N 天的日志文件
# 需要改的只有两处：LOG_DIR 和 DAYS

LOG_DIR="/var/log/myapp"
DAYS=7
LOGFILE="/var/log/clean-app-logs.log"

if [ ! -d "$LOG_DIR" ]; then
    echo "$(date '+%F %T') 目录不存在: $LOG_DIR" >> "$LOGFILE"
    exit 1
fi

echo "$(date '+%F %T') 开始清理 $LOG_DIR，阈值 ${DAYS} 天" >> "$LOGFILE"

find "$LOG_DIR" -type f -name "*.log" -mtime +$DAYS -print -delete >> "$LOGFILE" 2>&1

echo "$(date '+%F %T') 清理结束" >> "$LOGFILE"

几个参数的作用要写清楚：-type f 限定只处理普通文件，避免删到同名目录；-name "*.log" 把范围锁在日志后缀上；-mtime +7 表示修改时间在 7 天以前（不含今天）；-print 会把即将删除的文件名先写进日志，这是事后核对的关键；-delete 必须放在所有过滤条件之后。脚本写完后执行 chmod 750 /usr/local/sbin/clean-app-logs.sh，先手动跑一次，看 /var/log/clean-app-logs.log 里是否列出了预期文件。

Linux定时清理日志脚本文件在哪里

「在哪里」包含两个位置，容易混在一起：脚本文件本身放哪，以及定时任务从哪里读。确认方法很直接——脚本用 ls -l /usr/local/sbin/clean-app-logs.sh 看是否存在、属主和权限是否合理；定时任务用 crontab -l 看当前用户的任务，用 ls /etc/cron.d/ 看系统级任务目录里有没有别处放的同名任务。

Linux定时清理日志脚本文件夹

常见的落点有三类，需要结合主机现状确认用哪个：

  • /usr/local/sbin/ 或 /usr/local/bin/：自建脚本的常规位置，重启后仍在。
  • /etc/cron.d/：系统级定时任务，文件里需要多写一列执行用户，格式与 crontab -l 不同。
  • /etc/cron.daily/：只放脚本、不写时间表达式，由系统按日触发，具体触发时刻取决于 /etc/crontab 和 anacron 配置。

排查「任务没跑」时，先看 cron 自己的日志：Debian/Ubuntu 系通常在 /var/log/syslog 里用 grep CRON /var/log/syslog 查，RHEL/CentOS 系在 /var/log/cron 里查。这里能看到某时刻有没有启动过该命令，以及是否有 command not found 或权限报错。系统是否启用 cron 服务也要确认：systemctl status cron 或 systemctl status crond，服务名随发行版不同。

定时清理日志脚本文件：先把能核对的事实摆清楚

在改任何配置之前，先把下面这些能直接查到的信息列出来，避免凭印象动手。

  1. 日志目录的实际路径和文件命名：ls -lh /var/log/myapp | head -30，看文件名是否统一带 .log 后缀，有没有 .log.1、.gz 这类轮转产物。
  2. 文件的修改时间分布：find /var/log/myapp -type f -name "*.log" -mtime +7 | head，先只看不删，确认这条命令筛出来的正是你想删的。
  3. 哪些文件正被进程打开：lsof +D /var/log/myapp 或 ls -l /proc/*/fd 2>/dev/null | grep myapp，被持有的文件删掉后空间通常不会立即释放。
  4. 是否已有 logrotate 接管：ls /etc/logrotate.d/ 和 cat /etc/logrotate.d/myapp，有配置的话，按天轮转加 rotate N 已经能控制总量。
  5. 磁盘现状：df -h 看分区使用率，du -sh /var/log/myapp 看该目录占用。

这几项摆清楚后，「要不要写删除脚本」往往自己就有答案了：如果 logrotate 已存在只是配置里 rotate 数值偏大，改配置比新增脚本更稳；如果没有轮转机制、日志是应用自己按日期追加的，才轮到脚本处理。

定时清理日志脚本文件最容易搞错的一点

最常见的误解是把「按修改时间删除」等同于「删掉正在写的当前日志」。find -mtime +7 判断的是文件最后修改时间距离现在超过 7 天，正在被追加的日志修改时间是当下，不会被这条规则命中——但如果文件名匹配范围写得太宽，比如误用 *.log* 或漏写 -type f，就可能把当天日志或目录本身卷进去。

Linux定时清理日志脚本文件夹

能把两种情况区分开的检查动作是：把 -delete 去掉，只保留 -print 先跑一遍，对比输出清单和你预期要删的清单。下面这条命令就是干这个用的，它只打印不删除：

find /var/log/myapp -type f -name "*.log" -mtime +7 -printf "%TY-%Tm-%Td %TH:%TM  %s  %p\n"

输出里如果出现当天的日期，说明时间阈值或匹配条件有问题，此时不要加 -delete。另一个分界点是进程占用：如果某个日志文件的修改时间很旧但仍被进程打开（用 lsof 能查到），删掉它可能让进程继续往已删除的 inode 写，du 看不到、df 却不降。这种情况需要重启对应进程或改用 truncate，而不是靠清理脚本解决。

定时清理日志脚本文件：一个照着就能做完的做法

以下路径假设日志目录为 /var/log/myapp、保留 7 天、每天凌晨 3 点 20 分执行。换成自己的目录时，只改 LOG_DIR、DAYS 和 crontab 里的时间字段。

  1. 先确认目录存在且有日志文件：ls -ld /var/log/myapp && ls -lh /var/log/myapp | head。该步应看到目录属主和若干 .log 文件。
  2. 创建脚本（内容见第一节），保存为 /usr/local/sbin/clean-app-logs.sh，然后赋权：chmod 750 /usr/local/sbin/clean-app-logs.sh，chown root:root /usr/local/sbin/clean-app-logs.sh。
  3. 先做干跑验证，确认筛选结果：find /var/log/myapp -type f -name "*.log" -mtime +7 -print。该步应只列出明显陈旧的文件。
  4. 手动执行一次脚本：/usr/local/sbin/clean-app-logs.sh; echo $?。该步应返回 0，并在 /var/log/clean-app-logs.log 里看到「开始清理」「清理结束」两行和中间的文件列表。
  5. 写入定时任务，使用 root 身份执行 crontab -e，追加一行：
    20 3 * * * /usr/local/sbin/clean-app-logs.sh
    保存后用 crontab -l 核对是否写入成功，字段顺序为「分 时 日 月 周 命令」。cron 环境变量精简，脚本内一律写绝对路径，不依赖当前目录和自定义 PATH。
  6. 确认 cron 服务在运行：systemctl is-active cron（或 crond）。该步应返回 active。
  7. 次日核对结果：tail -30 /var/log/clean-app-logs.log 看是否有当天的执行记录；grep CRON /var/log/syslog | tail 或 grep clean-app /var/log/cron 看 cron 是否在 03:20 拉起过该命令；再用 du -sh /var/log/myapp 对比清理前的大小。

如果第 7 步只看到定时任务被启动、脚本日志却没有新增，通常是脚本没有可执行权限、shebang 路径不对，或者 cron 用户对该目录无读权限，按 /var/log/syslog 或 /var/log/cron 里的报错逐条排除即可。若该主机已有 logrotate 管理同一批日志，建议把脚本停掉，回到 /etc/logrotate.d/ 里调整保留份数和轮转周期，避免两套机制互相干扰。