通过配置logrotate结合systemd的ExecStoppost，在应用崩溃后自动切割日志。示例中myapp服务停止时触发logrotate强制切割/var/log/myapp.log，使用copytruncate确保不中断写入，实现异常归档便于排查。
linux系统中日志文件会不断增长，若不及时处理，可能占用大量磁盘空间甚至影响服务运行。logrotate 是 Linux 下标准的日志管理工具，支持按时间、大小等条件自动切割日志。虽然 logrotate 本身无法直接监听“应用程序崩溃”事件来触发日志切割，但可以通过结合脚本和配置，实现应用异常退出后自动归档日志的机制。
logrotate 基本原理与配置结构
logrotate 通常由 cron 每日执行，读取 /etc/logrotate.conf 和 /etc/logrotate.d/ 目录下的配置文件。每个配置定义了日志路径、切割策略、保留数量、压缩方式等。
示例基本配置：
/var/log/myapp.log { daily missingok rotate 7 compress delaycompress notifempty create 644 root root }
上述配置表示：每天检查 myapp.log，最多保留7份，旧日志使用 gzip 压缩，且在切割后创建新的空日志文件。
模拟“按崩溃切割”的实现思路
由于 logrotate 不支持事件驱动（如进程崩溃），需借助外部手段触发日志切割。常见做法是：当检测到应用异常退出时，主动调用 logrotate 切割对应日志。
可通过以下方式实现：
- 使用守护脚本监控应用进程状态，崩溃后执行日志切割命令
- 在应用启动脚本中加入前次日志清理逻辑
- 利用 systemd 服务的 Restart 和 ExecStopPost 执行清理动作
结合 systemd 实现崩溃后日志切割实例
假设有一个名为 myapp 的应用，其日志写入 /var/log/myapp.log。我们希望每次应用崩溃重启后，自动切割上一次的日志。
1. 配置 logrotate 规则
创建配置文件 /etc/logrotate.d/myapp：
/var/log/myapp.log { size 1k rotate 5 copytruncate compress missingok notifempty create 644 root root }
说明：
- size 1k：仅用于测试，实际可设为 10M 或更大
- copytruncate：复制日志后清空原文件，适用于应用无法重新打开日志的场景
- 不依赖时间触发，而是手动调用 logrotate 生效
2. 配置 systemd 服务文件
编辑服务文件 /etc/systemd/system/myapp.service：
[Unit] Description=My Application After=network.target <p>[Service] ExecStart=/usr/local/bin/myapp Restart=always RestartSec=5 ExecStopPost=/usr/sbin/logrotate -f /etc/logrotate.d/myapp</p><p>[Install] WantedBy=multi-user.target
关键点：
- ExecStopPost 在服务停止后执行（包括崩溃退出）
- -f 强制执行：即使未到切割条件也立即切割日志
这样，无论应用正常停止还是崩溃，systemd 都会触发 logrotate 强制切割日志。
补充：使用监控脚本主动触发切割
若不使用 systemd，可编写简单监控脚本：
#!/bin/bash while true; do if ! pgrep myapp > /dev/null; then /usr/sbin/logrotate -f /etc/logrotate.d/myapp sleep 2 systemctl start myapp # 或重启应用 fi sleep 10 done
将此脚本作为守护进程运行，可实现类似效果。
基本上就这些。通过合理配置 logrotate 并结合进程管理机制，就能实现“类崩溃触发”的日志切割行为，确保问题发生时的日志独立归档，便于后续排查。关键是利用 copytruncate 或外部触发避免服务中断。