restart=on-failure + restartsec=5 + startlimitintervalsec=60 + startlimitburst=3 是 systemd 服务安全重启的黄金组合，避免无限循环重启与资源耗尽。
systemd 服务崩溃后自动重启怎么配才不翻车
直接配 Restart=always 很容易导致服务反复启动失败、打满 CPU，甚至把数据库进程反复 kill 掉引发数据不一致。关键不是“要不要重启”，而是“什么条件下重启”和“重启前/后做什么”。
-
Restart=on-failure是更安全的默认选择：只在进程非零退出、被SIGSEGV或OOMKilled时触发，跳过正常exit 0场景 - 必须加
RestartSec=5：避免秒级循环重启；对冷启动慢的服务（如 Java 应用），建议设为10或15 - 强制加上频率限制：
StartLimitIntervalSec=60+StartLimitBurst=3，超限后 systemd 会停手并标记start-limit-hit，这时就得人工查日志了 - 改完别忘了
systemctl daemon-reload和systemctl restart xxx.service，否则配置不生效
e2fsck 修复 ext4 文件系统时最常误操作的三件事
遇到 EXT4-fs (sda1): unable to read superblock 别急着跑 e2fsck /dev/sda1 —— 这个命令默认只读主 superblock，一错就可能让元数据雪上加霜。
- 先查备份 superblock 位置：
dumpe2fs -h /dev/sda1 2>/dev/null | grep -i "superblock backup"，常见位置有8193、32768、98304 - 用
-n只读模式验证：e2fsck -n -b 8193 /dev/sda1，能成功说明备份块可用，再执行带-b的修复 - 看到
UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY，优先用e2fsck -p /dev/sda1自动预修复；-y虽省事但会把所有孤儿 inode 直接丢进/lost+found，文件名全丢，后期根本没法认
监控告警到自动恢复之间，为什么总差那么一口气
很多团队装了 Prometheus、配了 Alertmanager，但告警来了还得手动登录服务器敲命令——问题不在监控，而在“决策”环节缺失。自动恢复卡在“该不该动”“怎么动”“动错了怎么办”这三关。
- 告警不能只发 Slack：Alertmanager 的
webhook必须对接一个轻量脚本，比如收到NodeFilesystemSpaceFillingUp告警后，自动清理/var/log/journal或清空/tmp下 7 天前的文件 - 脚本必须幂等：
rm -f /tmp/*.log安全，rm -rf /tmp/*危险；每次运行结果应可预期，重复执行无副作用 - 所有动作必须记日志：用
logger -t auto-heal "cleaned /tmp, freed 2.1G"，而不是只写到 stdout；否则故障复盘时连“有没有执行过”都搞不清 - 拒绝黑盒操作：像
systemctl restart mysql这类高风险动作，脚本里得先检查mysqladmin ping是否响应、mysqld进程是否存在，再决定是否重启
MinIO 集群节点宕机后，mc admin heal 不是万能解药
mc admin heal 确实能修复部分对象损坏，但它不处理节点下线后的数据重平衡，也不保证服务不中断。真实场景中，它只是恢复链条里的一环。
- 先确认节点状态：
mc admin info myminio看哪些节点offline，别只盯着heal输出的“healed objects”数字 - 替换节点前，用
mc admin service restart尝试软恢复；若无效，再物理下线旧节点、部署新节点，并确保MINIO_ROOT_USER和证书完全一致 -
mc admin heal -r myminio/mybucket是递归修复，但耗 I/O；生产环境建议在低峰期跑，且提前用mc stat查看 bucket 对象数，预估耗时 - 真正防止单点失效的是 Erasure Coding 配置：部署时就该用
4+2或更高，而不是等故障了再指望heal把坏盘数据拼回来
自动恢复不是写个脚本扔 cron 就完事。最难的部分永远在边界判断：什么时候该修，什么时候该报，什么时候该停。日志没留全、权限没设对、幂等没保障——这些细节不抠清楚，自动化反而会成为故障放大器。
