.png)
我的空间错误日志中有这个：
[2009 年 9 月 18 日星期五 08:10:54] [通知] 子进程 pid 9178 退出信号分段错误 (11)
[2009 年 9 月 18 日星期五 08:11:41] [通知] 子进程 pid 9187 退出信号分段错误 (11)
[2009 年 9 月 18 日星期五 08:12:12] [通知] 子进程 pid 9204 退出信号分段错误 (11)
[2009 年 9 月 18 日星期五 08:12:13] [通知] 子进程 pid 9202 退出信号分段错误 (11)
[2009 年 9 月 18 日星期五 08:14:45] [通知] 子进程 pid 9251 退出信号分段错误 (11)
在我添加 vhost.conf 文件的那天，它就开始了。所以我恢复到原始文件并重新启动了 apache2ctl。不幸的是，它仍然在发生。
Apache 似乎正在正常提供页面服务。
有任何想法吗？
干杯，
內森。
答案1
Nathan，尝试停止 Apache，然后在后台启动它（调试，非线程），这可能会泄露更多关于导致其出现段错误的线索。
话虽如此，无论如何它都不应该发生段错误，所以它是一个错误，尽管如此，如果你知道是什么原因造成的，你也许可以修复它。
apache2 -X
此外（不太可能揭示该问题的全部原因），任何警告/错误来自......
apache2ctl -t
...？
最后，您加载到 Apache 中的所有模块是否都已“认证”，也许您可以注释掉其中一半左右的模块，看看问题是否消失，然后从那里继续进行分治二分搜索。
您可能还会查找由段错误生成的任何核心转储，也许是在 /tmp 中？如果确实找到了，请尝试通过 gdb 运行它...
gdb apache2 -c /tmp/core.<pid>
答案2
Sig11 通常仅由于以下两个原因之一而发生：
糟糕的程序。
就 Apache 而言，从统计上来说，这不太可能是核心 Apache 代码中的错误。
更常见的是模块故障。要么是模块安全地处理代码或正在处理的库中的异常的方式有问题。要么是它与 Apache 选择的 MPM 模型交互的方式有问题。当模块以这种方式行为不当时，它会在将数据返回给 Apache 子进程之前不受控制地退出，从而产生段错误。
查看自上次运行以来所做的所有更改。例如李斌说，这是使用版本控制的完美示例。
graceful稍微复杂一点的是，在更改 Apache 模块设置后，您通常可以通过发出而不是完全重新启动来产生相同的行为。您可以通过停止并启动 Apache 来排除这种情况。硬件不好。
如果您确定错误与您的配置更改相符，并且您没有看到系统上任何其他不良影响，那么您可能可以排除这种情况。但是如果您没有其他途径，可能值得考虑。CPU 和 RAM 是典型的罪魁祸首。
答案3
终于解决了这个问题。只需重启服务器即可解决段错误。
谢谢你的回答。我相信这对诊断未来的问题很有用。
內森。
答案4
在花了几个小时试图找出我自己的分段错误的原因后，我开始随机禁用一些东西。对我来说，错误的原因是 Zend 的 eaccelerator。
由于我不需要此扩展，因此我将其禁用。如果您遇到同样的问题并且需要此扩展，您可以尝试删除 eaccelerator 缓存并重新启动 httpd。