关键不是选工具，而是匹配环境与可靠性要求：systemd是现代发行版默认且最稳妥的选择，supervisor适合多进程托管或旧系统，nohup/screen仅属临时补救，不构成真正守护机制。
Linux 中配置进程守护机制，关键不是“选哪个工具”，而是根据运行环境、维护成本和可靠性要求匹配方案。systemd 是现代发行版默认且最稳妥的选择；Supervisor 适合多进程托管或旧系统；nohup/screen 只能算临时补救，不能算“配置守护机制”。
用 systemd 管理单个服务（推荐生产环境）
这是当前主流发行版（RHEL/CentOS 8+、Ubuntu 16.04+、Debian 9+）的标准做法，支持开机自启、崩溃自动重启、日志集成、资源限制等完整生命周期管理。
-
Type=simple适用于前台运行的程序（如python3 app.py）；若程序自己 fork 成后台 daemon，应改用Type=forking并配PIDFile= -
User=必须显式指定，避免以 root 运行——常见错误是漏写导致权限过高或日志写入失败 -
Restart=on-failure比always更合理：正常退出（如收到SIGTERM）不应重启，否则可能干扰滚动更新 - 日志默认走 journald，查日志用
journalctl -u myapp.service -n 50；若需文件日志，加StandardOutput=append:/var/log/myapp.log，但会绕过 journalctl 时间戳和结构化字段
用 Supervisor 托管多个同类型进程（如爬虫集群）
Supervisor 不依赖系统 init，适合在容器内、老旧系统（如 CentOS 7）或需要统一管理多个相似子进程的场景。它不接管系统级依赖，但对进程本身状态控制更细粒度。
-
command必须是前台命令：如果启动脚本里写了&或调用了nohup，Supervisor 就无法感知进程是否存活 -
autorestart=true默认对所有退出码重启；若程序支持优雅退出（如返回码 0 表示正常关闭），应设为autorestart=unexpected -
environment中的PYTHONPATH或PATH容易遗漏，导致ImportError或找不到可执行文件 - 配置生效必须执行
supervisorctl reread && supervisorctl update，只 reload 不加载新配置文件
避免用 nohup 或 screen 当守护方案
它们根本不算“守护机制”，只是屏蔽了 SIGHUP 信号或隔离了终端会话。一旦 shell 退出、SSH 断连或父进程被 kill，进程可能意外终止，且无状态监控能力。
-
nohup python3 server.py > log.txt 2>&1 &的常见陷阱：log.txt 会持续增长，没有轮转；进程崩溃后不会自动拉起 -
screen -dmS myapp python3 server.py问题更隐蔽：screen 会话可能被系统清理（如 loginctl cleanup-sessions），或因 OOM 被杀而无记录 - 两者都不记录进程 PID，
ps aux | grep查找不可靠，无法做健康检查或依赖管理
真正要“配置守护机制”，核心就两条：一是让进程脱离终端控制并由系统级服务管理器领养，二是建立可验证的存活反馈路径。systemd 和 Supervisor 都满足，而 nohup 不满足后者。最容易被忽略的是用户权限与日志路径的写入权限匹配——哪怕配置全对，/var/log/myapp/ 目录属主不是 User= 指定的用户，服务也会静默失败。
