如何解决宝塔面板面板日志文件过大占用空间_配置logrotate日志切割与定期自动清理脚本-php教程-PHP中文网

宝塔日志需手动配置logrotate实现轮转，因默认不接管系统日志机制且nginx等服务无内置切割功能；须新建/etc/logrotate.d/bt-logs配置，启用daily、create、sharedscripts及postrotate调用kill -usr1等指令，并配合find定期清理90天前压缩包。

如何解决宝塔面板面板日志文件过大占用空间_配置logrotate日志切割与定期自动清理脚本

宝塔面板日志文件（尤其是 bt、nginx、apache 和站点访问日志）长期不处理，很容易突破 10GB 甚至几十 GB，直接拖慢服务器 IO、挤占磁盘空间——这不是配置问题，是没启用日志轮转机制。

为什么宝塔默认不自动切割日志？

宝塔本身不接管系统级日志轮转逻辑，/www/wwwlogs/ 下的站点日志、/www/server/panel/logs/ 下的面板日志，均由各自服务（Nginx/Apache/Python 进程）直接追加写入，无内置 rotate 控制。系统自带的 logrotate 默认只管 /var/log/ 下的标准路径，不会扫描宝塔自定义目录。

logrotate 不会自动发现 /www/wwwlogs/ 或 /www/server/panel/logs/
即使手动添加配置，若未指定 create 和 dateext，旧日志可能被覆盖而非归档
Nginx 的 access_log 指令不支持动态重开文件，必须配合 kill -USR1 通知 reload 才能切日志

手动配置 logrotate 管理宝塔日志（含 Nginx reload）

在 /etc/logrotate.d/bt-logs 新建配置文件，内容如下：

"/www/wwwlogs/*.log" "/www/server/panel/logs/*.log" {
    daily
    missingok
    rotate 30
    compress
    delaycompress
    notifempty
    create 644 www www
    sharedscripts
    postrotate
        if [ -f /www/server/nginx/logs/nginx.pid ]; then
            kill -USR1 `cat /www/server/nginx/logs/nginx.pid`
        fi
        if [ -f /www/server/apache/logs/httpd.pid ]; then
            /www/server/apache/bin/httpd -k graceful
        fi
    endscript
}

必须用双引号包裹通配路径，否则 logrotate 无法识别含空格或特殊字符的站点名
sharedscripts 确保所有匹配文件共用一次 postrotate，避免对每个 .log 都执行一遍 reload
create 644 www www 是关键：Nginx 日志属主是 www，不设权限会导致新日志无法写入
delaycompress 防止刚切完就压缩，留出人工检查窗口；压缩实际发生在下次 rotate 时

验证 logrotate 是否生效 & 排查常见失败点

别等明天才看效果，立刻用 dry-run 测试：

logrotate -d /etc/logrotate.d/bt-logs

重点关注输出里是否出现 rotating pattern 和 running postrotate script。如果没看到，常见原因有：

路径不存在或权限不足：ls -l /www/wwwlogs/ 看是否可读，ps aux | grep nginx 确认 pid 文件路径是否匹配配置中的 /www/server/nginx/logs/nginx.pid
postrotate 脚本里用了绝对路径但命令不在 $PATH 中（比如某些系统 kill 在 /bin/kill），建议显式写 /bin/kill -USR1
日志文件正在被进程锁住（如 Python 后台脚本直接 open 写日志），lsof +D /www/wwwlogs/ 查看谁在占用
配置文件末尾漏了 } 或缩进错乱，logrotate 会静默跳过整个块

额外加一层保险：用 crontab 定期清理超期压缩包

logrotate 只管 rotate 和压缩，但压缩后的 .log.1.gz、.log.2.gz… 仍长期残留。加个简单清理脚本防堆积：

/usr/bin/find /www/wwwlogs/ /www/server/panel/logs/ -name "*.log.*.gz" -mtime +90 -delete

放入 crontab -e，例如每周日凌晨运行：

0 0 * * 0 /usr/bin/find /www/wwwlogs/ /www/server/panel/logs/ -name "*.log.*.gz" -mtime +90 -delete

务必用绝对路径调用 find，crontab 的 PATH 很窄，find 可能找不到
-mtime +90 表示“修改时间超过 90 天”，不是“创建时间”；压缩包的 mtime 就是压缩完成时间，符合预期
不要用 rm -f /www/wwwlogs/*.gz 这类通配删除，容易误删正在使用的临时压缩文件

最易被忽略的是 Nginx 的 USR1 信号是否真被接收——tail -f /www/server/nginx/logs/error.log 看 reload 时有没有 reopening logs 提示；没有的话，说明 postrotate 没跑成功，得回退查权限或 pid 路径。