crontab不自动执行日志切割，首要排查cron服务是否运行及logrotate是否被调用；需检查systemctl状态、/etc/cron.daily/logrotate可执行性、logrotate配置语法、usr1信号发送及执行时间机制。
crontab 不自动执行日志切割，大概率不是脚本写错了，而是 cron 服务根本没在跑，或者 logrotate 没被真正调用 —— 先确认基础链路是否通。
检查 cron 服务是否实际运行
crontab 只是配置入口，背后依赖 cron（Ubuntu/Debian）或 crond（CentOS/RHEL）守护进程。服务停了，再准的定时任务也压根不会触发。
- 运行
sudo systemctl status cron或sudo systemctl status crond，看输出里有没有active (running) - 如果显示
inactive (dead)或failed，直接启动：sudo systemctl start cron（或crond），再加自启：sudo systemctl enable cron - 注意：某些最小化安装系统（如部分 Docker 镜像、Alpine）默认不装 cron，得先
yum install cronie或apt install cron
验证 /etc/cron.daily/logrotate 是否真被调用
logrotate 默认靠系统级 daily 任务驱动，路径是 /etc/cron.daily/logrotate。但它不是“只要放那儿就自动跑”，得满足三个条件：
- 该文件必须是可执行的（
chmod +x /etc/cron.daily/logrotate） - 系统得有
anacron或完整 cron 支持；某些云服务器禁用 anacron，/etc/cron.daily/下的脚本可能被跳过 - 手动模拟执行一次：
sudo run-parts --test /etc/cron.daily看logrotate是否在列表里；再试真实执行：sudo run-parts /etc/cron.daily
你的 logrotate 配置没被加载或语法错误
logrotate 不报错就静默失败很常见。它读取 /etc/logrotate.conf，再 include /etc/logrotate.d/ 下所有文件 —— 但只要其中任一配置语法错，整条链都可能中断。
- 用 debug 模式验证单个配置：
sudo logrotate -d /etc/logrotate.d/bt-logs，重点看输出末尾有没有error:或skipping - 常见坑：
create指令后漏权限/用户（如create 644 www www），或路径写成相对路径（必须绝对路径，如/www/wwwlogs/*.log） - 宝塔日志路径需显式声明，logrotate 不会自动扫描
/www/下任何子目录
nginx 或面板进程没收到 USR1 信号（仅限 shell 脚本方案）
如果你没走 logrotate，而是自己写了 cut-log.sh + crontab，那关键一步常被忽略：移动日志后必须通知 nginx 重开文件句柄，否则新日志仍写进旧文件名里。
- 检查脚本里是否有
kill -USR1 $(cat /www/server/nginx/logs/nginx.pid)这行（注意 pid 文件路径要和你 Nginx 实际一致） - pid 文件不存在？可能是 Nginx 没启用 pid 配置，或路径不对；先
ps aux | grep nginx找主进程 PID，临时改成kill -USR1 <pid></pid>测试 - 权限问题：crontab 默认以 root 运行脚本，但若你用普通用户 crontab（
crontab -e未加 sudo），则无权读 pid 或发信号
最易被忽略的一点：logrotate 的 daily 执行时间由系统决定（通常是凌晨 06:25 左右），不是你 crontab 里写的 0 0 * * * 就立刻生效；调试阶段建议先用 logrotate -f 强制触发，再观察日志和文件变化，比干等一夜更可靠。
