Supervisor不保证“永不宕机”，仅在进程意外退出后自动重启；根本问题如代码异常、端口冲突等需自行定位修复。
Supervisor 本身不保证“永不宕机”，它只是在进程意外退出后自动拉起——如果 Web 服务反复崩溃，Supervisor 会不断重启，但根本问题（如代码异常、端口冲突、内存溢出）必须你自己定位和修复。
supervisord 启动失败：常见配置路径与权限问题
启动 supervisord 时提示 “Error: Cannot open an HTTP server: socket.error: [Errno 13] Permission denied” 或 “Config file /etc/supervisor/conf.d/xxx.conf does not exist”，本质是权限或路径配置错位。
-
/etc/supervisor/conf.d/是 Debian/Ubuntu 默认包含目录，但 supervisor 不会自动创建它；需手动sudo mkdir -p /etc/supervisor/conf.d - 配置文件必须以
.conf结尾，且内容里[program:myweb]的名字不能含空格或特殊字符 - 若用非 root 用户运行
supervisord（比如supervisord -c ~/supervisord.conf），则stdout_logfile和stderr_logfile路径必须对该用户可写，否则启动直接静默失败 - Windows 下不支持 supervisor；macOS 需用
brew install supervisor，且默认不监听 HTTP 端口（inet_http_server段需显式启用）
Web 进程反复重启：autostart、autorestart 与 startretries 的真实作用
很多人以为设了 autorestart=true 就万事大吉，其实 supervisor 对“崩溃”的判断很机械：只要子进程 exit code ≠ 0，就视为失败。而很多 Web 框架（如 Flask、FastAPI）在开发模式下 Ctrl+C 退出是正常行为，但被 supervisor 当成异常。
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
-
autostart=true：仅控制 supervisord 启动时是否立刻拉起该程序；不影响后续崩溃行为 -
autorestart=unexpected（推荐）：只在非 0、非指定 exitcodes 时重启；避免因sys.exit(0)或信号退出被误判 -
startretries=3：不是“最多重启 3 次”，而是“连续 3 次启动失败后停止尝试”；若想无限重试，保持默认值3并配合autorestart=unexpected即可 - 务必加
stopasgroup=true和killasgroup=true：否则 Flask 的debug=True模式会 fork 子进程，supervisor 只 kill 主进程，子进程残留并占端口
日志查不到崩溃原因？stdout_logfile 和 redirect_stderr 必须配对
很多用户发现 supervisorctl tail myweb stderr 返回空，或者日志里只有启动信息、没有 traceback —— 这是因为 Python 默认将异常输出到 stderr，但 supervisor 默认不捕获它。
立即学习“Python免费学习笔记（深入）”；
- 必须显式设置
redirect_stderr=true，否则stderr_logfile不生效 -
stdout_logfile=/var/log/myweb.log和stderr_logfile=/var/log/myweb.err要分开；合并写入同一文件会导致日志交错难读 - Python 程序内部若用了
logging.basicConfig()且没指定filename，日志仍走 stdout/stderr，所以 supervisor 日志配置是第一道拦截 - 临时调试可用
supervisorctl restart myweb; supervisorctl tail myweb stdout快速验证输出是否被捕获
真正卡住的点往往不在配置语法，而在进程模型本身：Gunicorn 要用 --preload 避免 fork 后的模块状态混乱，Uvicorn 要加 --loop uvloop 但得确认环境已安装，而所有这些，supervisor 都不管——它只管那个最外层的 command= 进程是否活着。
