Linux不会因内存溢出自动重启，而是触发OOM Killer终止进程；推荐通过systemd配置MemoryLimit、OOMScoreAdjust和Restart实现服务级防护，而非系统级重启。
Linux 本身不会因为“内存溢出”自动重启——它会先用 OOM Killer 杀进程，而不是 reboot。真要自动重启，得自己加逻辑或调内核参数，但两者目的和风险完全不同。
OOM Killer 触发后要不要重启？
当系统内存耗尽，内核会启动 OOM Killer，选一个进程杀掉（比如你的 python app.py 或 java 进程），日志里会出现类似：
kernel: Out of memory: Killed process 12345 (python) total-vm:4096000kB, anon-rss:3072000kB
这说明系统“活下来了”，只是干掉了某个进程。此时自动重启不是默认行为，也不推荐直接 reboot —— 因为杀掉一个服务比整个系统重启代价小得多。
- 如果你的服务被杀后无法自恢复（比如没配
systemd自动重启），那问题在服务管理，不是内存策略 - 如果频繁触发 OOM Killer，优先查内存泄漏、调
MemoryLimit或改OOMScoreAdjust，而不是绕过它去 reboot - 直接 reboot 会导致所有服务中断，可能丢数据、断连接，比杀单个进程破坏性大得多
systemd 服务级内存保护怎么配
对 Pi0、Flask、Gradio 这类 Python 服务，最实用的防护不是全局 reboot，而是让服务自己扛住或优雅退出再拉起：
- 在
/etc/systemd/system/pi0.service的[Service]段加：MemoryLimit=1.5G—— 超过就由 systemd 主动 kill，避免拖垮整机 - 加：
OOMScoreAdjust=-500—— 降低被内核 OOM Killer 选中的概率（范围 -1000 到 1000） - 加：
Restart=on-failureRestartSec=10—— 进程退出（包括被 OOM Killer 杀）后 10 秒自动重启 - 别漏掉：
StartLimitIntervalSec=0—— 否则 systemd 默认 10 秒内失败 5 次就放弃重启
这样配置后，pi0 即使因内存爆掉被杀，也会立刻重新加载，用户几乎感知不到中断。
真要系统级自动 reboot，只适用于极端场景
比如你确认某硬件/驱动有严重 bug，OOM 后系统必然卡死（soft lockup），且无法靠杀进程恢复——这时才考虑内核 panic 自动重启：
- 运行：
echo 1 | sudo tee /proc/sys/kernel/panic—— 设置 panic 后秒数为 0，即立即重启 - 配合：
echo 1 | sudo tee /proc/sys/kernel/watchdogecho 1 | sudo tee /proc/sys/kernel/soft_watchdog—— 开启 watchdog 监控 CPU 假死 - 注意：
/proc/sys/设置重启后失效，要永久生效得写进/etc/sysctl.conf，加一行：kernel.panic = 1
这种配置会让系统在 kernel panic 时重启，但它不响应 OOM Killer —— OOM 是正常内存管理机制，不是 panic。强行混用容易把可恢复的问题变成不可控重启。
用 cron + free 检测后 reboot 是危险操作
网上流传的“每 5 分钟跑一次 free 看内存超 80% 就 reboot”脚本，实际非常粗糙：
-
free显示的 “used” 包含 cache/buffer，不能真实反映应用压力；MemAvailable才是关键指标 - 脚本里用
bc或awk算百分比，但没处理空值、单位、多行输出，极易误判 - 没有区分是临时缓存高还是真泄漏；一次 spike 就 reboot，比 OOM Killer 更武断
- 没加锁机制，多个实例并发执行可能导致重复 reboot
如果你非要用脚本，至少改成检查 /proc/meminfo 中的 MemAvailable，并设阈值（比如低于 256M）再动作，且优先 systemctl restart pi0，而不是 reboot。
真正难的不是写个 reboot 脚本，而是判断：这个内存上涨是暂时的 cache，还是进程持续 leak，还是系统本身配置太小。看 journalctl -k | grep -i "out of memory" 和 systemd-analyze blame，比盲目重启更有价值。
