Apache每日收到SIGTERM信号后意外终止，原因何在？

看起来你遇到的是Apache每日意外终止的问题，日志里只显示收到SIGTERM信号，结合你的环境（Debian系统、Nginx处理静态资源、Apache跑PHP+Python后端，还有之前的磁盘耗尽和SSL代理配置历史），我整理了几个关键的排查方向和解决思路：

SIGTERM是正常的终止信号，但Apache自己不会随便触发它，大概率是外部进程或者系统机制发来的：

• 检查systemd的服务日志：Debian用systemd管理服务，运行journalctl -u apache2 --since "1 day ago"，看看有没有服务被重启的记录——比如OOM Killer（内存不足杀手）触发的终止，或者systemd的超时、重启策略导致的停止。
• 排查OOM Killer痕迹：内存耗尽是常见的Apache被终止的原因，虽然Apache日志只记SIGTERM，但系统日志会有记录。运行dmesg | grep -i oom或者grep -i oom /var/log/syslog，如果看到类似Out of memory: Killed process的内容，那就是内存不够导致的。
• 检查定时任务：看看有没有cron脚本或者定时进程在主动终止Apache。可以用crontab -l查看当前用户的定时任务，再检查/etc/cron.d/、/etc/cron.hourly/、/etc/cron.daily/这些系统级定时目录，有没有可疑的脚本。

之前出现过磁盘满的情况，可能留下了一些隐性问题：

• 检查Apache相关目录的权限和完整性：比如/var/log/apache2/、/var/run/apache2/这些目录，确保www-data用户/组有读写权限。磁盘满可能导致文件系统出现错误，必要时可以在单用户模式下运行fsck检查文件系统（操作前记得备份数据）。
• 清理临时文件：/tmp/目录如果堆积了大量未清理的PHP/Python临时文件，会占用磁盘空间甚至导致进程无法写入临时数据。可以手动清理/tmp/下的过期文件，或者配置应用的临时目录到有足够空间的分区。

数月前配置的SSL代理可能存在优化空间，间接导致Apache资源耗尽：

• 优化SSL加密配置：如果Apache的SSLCipherSuite、SSLProtocol配置了老旧或低效的加密套件，会导致连接占用更多资源，内存和CPU飙升。建议禁用SSLv3、TLSv1.0这些旧协议，使用现代高效的加密套件（比如ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256）。
• 调整代理超时设置：Nginx和Apache之间的代理超时不匹配，可能导致大量僵死连接堆积，耗尽Apache的prefork进程。检查Apache的Timeout、KeepAliveTimeout，以及Nginx的proxy_connect_timeout、proxy_read_timeout，确保两边的超时设置协调，避免连接长时间占用资源。

你用的是mpm_prefork模式，进程数设置不合理很容易导致资源耗尽：

• 检查mpm_prefork.conf配置：重点看StartServers、MinSpareServers、MaxSpareServers、MaxRequestWorkers、MaxConnectionsPerChild这些参数。每个prefork进程大概占用20-50MB内存，根据服务器总内存合理设置MaxRequestWorkers——比如4GB内存的话，设置在60-80左右比较稳妥（避免占满内存触发OOM）。
• 启用mod_status监控：配置Apache的mod_status模块，开启状态页面，这样可以实时查看Apache的进程数、连接数、请求数，有没有异常的进程堆积或者资源占用飙升。

在排查期间，为了避免服务中断，可以让systemd自动重启Apache：
编辑/etc/systemd/system/multi-user.target.wants/apache2.service文件，添加或修改以下配置：

Restart=always
RestartSec=5

然后运行systemctl daemon-reload和systemctl restart apache2，这样Apache意外退出后会自动重启。

内容的提问来源于stack exchange，提问作者JAL