apache + mod_wsgi守护进程模式自带崩溃自动重启能力，通过maximum-requests和restart-interval可防内存泄漏，python应用须禁用debug=true和自启daemon，避免脱离管控。

Apache 本身不直接依赖外部守护进程来实现 Python 应用的崩溃重启——它的稳定性由 mod_wsgi 的运行模式和 Apache 自身的进程管理机制保障。但如果你的 Python 应用（比如 Flask/FastAPI）是通过 WSGI 部署在 Apache 上，而它又因代码异常、内存泄漏或第三方库问题频繁退出，导致 mod_wsgi 子进程挂掉、返回 500 或超时，这时就需要分层处理：Apache 层负责回收异常子进程并拉起新实例，而应用层需避免自行 daemon 化、正确响应信号，并可辅以 Supervisor 做兜底监控。

Apache + mod_wsgi 已内置“自动重启”能力

mod_wsgi 在守护进程模式（WSGIDaemonProcess）下，默认启用子进程生命周期管理：

• 子进程崩溃后，Apache 会自动创建新进程替代，无需额外配置；
• 通过 maximum-requests（如设为 1000）可强制子进程定期轮换，防内存累积；
• 用 restart-interval（如 3600）可限制单个子进程最长运行时间；
• 错误日志（ErrorLog）中出现 segmentation fault 或 child process exited with code 时，说明 mod_wsgi 已捕获崩溃并完成替换。

Python 应用必须禁用 self-daemonize 和 debug 模式

如果 Python 代码里调用了 os.fork()、使用了 python-daemon，或 Flask 启动时写了 debug=True，会导致：

python-code-analyz

专业Python代码分析与优化，支持语法检查、安全扫描、性能评估、复杂度分析及重构后优化代码生成。

下载

• 实际业务进程脱离 mod_wsgi 管控，变成孤儿进程；
• Apache 只监控到 WSGI 启动器退出，无法感知真正服务是否存活；
• 崩溃后不触发子进程重建，页面持续 503。

务必确保：
– WSGI 入口文件（如 wsgi.py）中没有 app.run() 或 debug=True；
– 不调用任何 daemon 包或手动 fork；
– 所有初始化逻辑（DB 连接、缓存加载）放在模块顶层或 application 对象创建时，而非请求处理中。

Supervisor 可作为 Apache 外层兜底（慎用）

Supervisor 不该直接托管 httpd 或 apache2 进程（systemd 已做更好），但它可用于监控你的 Python 应用独立运行场景（例如你临时改用 gunicorn 替代 mod_wsgi）：

• 停用 Apache 的 WSGI 部署，改用反向代理（ProxyPass）转发到 gunicorn；
• Supervisor 配置中必须设 autorestart=true、startsecs=5、stopasgroup=true；
• command 必须用绝对路径，且禁用 --daemon（gunicorn 要加 --daemon=False）；
• 避免与 Apache 冲突：监听端口不能和 Apache 相同，建议用 127.0.0.1:8000 类本地地址。

排查是否真“崩溃”还是配置/权限问题

很多所谓“自动重启失效”，其实是启动阶段失败未被识别：

• 检查 mod_wsgi 日志和 Apache ErrorLog，确认是 ImportError、Permission denied 还是段错误；
• Python 虚拟环境路径是否在 WSGIDaemonProcess 中用 python-path 正确声明；
• SELinux 或 AppArmor 是否拦截了子进程访问数据库或 socket；
• 用 ps auxf | grep wsgi 查看子进程 PPID 是否为 Apache 主进程（PID=1 的 httpd 进程）。

Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！