我在我的ace error.log中有这个：
[Fri Sep 18 08:10:54 2009] [notice]子pid 9178退出信号分段故障（11）
[Fri Sep 18 08:11:41 2009] [注意]子pid 9187退出信号分段故障（11）
[Fri 2009年9月18日08:12:12 [通知]子pid 9204退出信号分段故障（11）
[星期五] 18月18：08：12：12 [注意]子pid 9202退出信号分段故障（11）
[星期五9月18日2009年08:14:45] [通知]子pid 9251退出信号分段错误（11）
从添加vhost.conf文件的同一天开始。因此我恢复了原始文件，并重新启动了apache2ctl。不幸的是，它仍在发生。
Apache似乎正在提供页面。
有任何想法吗？
干杯，
内森
Answers:
内森（Nathan），尝试停止Apache，然后在前台（调试，非线程）启动它，这可能会泄漏出更多有关导致段错误的信息。
话虽如此，它无论如何都不应该进行段错误处理，因此它是一个错误，但是，如果您知道导致错误的原因，则可以修复。
apache2 -X
另外（不太可能揭示此问题的全部原因），来自...的任何警告/错误
apache2ctl -t
...？
最后，是所有已加载到Apache“ Certified”的模块，也许您可以注释掉其中的一半，看看问题是否消失，然后从那里进行分而治之的二进制搜索。
您可能还会在/ tmp中查找从segfault生成的任何核心转储？如果确实找到了一些，请尝试通过gdb运行它。
gdb apache2 -c /tmp/core.<pid>
Sig11的出现通常仅出于以下两个原因之一：
错误的程序。
就Apache而言，从统计上讲不可能是Apache核心代码中的错误。
发生模块故障更常见。模块以安全方式处理其正在处理的代码或库中的异常的两种方式。或它与Apache选择的MPM模型进行交互的方式。当模块以这种方式出现异常时，它将无法控制地退出，然后再将数据返回给Apache子进程，从而产生段错误。
查看自上次生效以来所做的所有更改。就像Lee B所说的那样，这是使用版本控制的完美示例。
为了使事情复杂化，graceful在更改Apache的模块设置后，通常通过发出a 而不是完全重新启动来产生相同的行为。您可以通过停止并启动Apache来排除这种情况。
硬件不良。
如果您确定错误与配置更改同时发生，并且您没有在系统上看到任何其他不良影响，则可以排除这种情况。但是，如果您用光了其他途径，可能值得牢记。CPU和RAM是典型的罪魁祸首。
花了几个小时试图找出我自己的细分错误错误的原因之后，我开始随机禁用一些东西。就我而言，错误的原因是Zend的加速器。
由于我不需要此扩展程序，因此我将其禁用。如果您遇到相同的问题并且需要此扩展名，则可以尝试删除eaccelerator缓存并重新启动httpd。
下次您可以尝试使用strace或truss