php (notice) child pid XXXX exit signal Segmentation fault (11), 可能coredump in /etc/apache2

(notice) child pid XXXX exit signal Segmentation fault (11), possible coredump in /etc/apache2

提问by Jason

I keep getting the follow error in my Apache log:

我的 Apache 日志中不断出现以下错误：

[Wed Sep 18 17:59:20 2013] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.8 with Suhosin-Patch configured -- resuming normal operations
[Wed Sep 18 18:06:30 2013] [notice] child pid 7505 exit signal Segmentation fault (11), possible coredump in /etc/apache2
[Wed Sep 18 18:06:35 2013] [notice] child pid 7497 exit signal Segmentation fault (11), possible coredump in /etc/apache2
[Wed Sep 18 18:13:53 2013] [notice] child pid 7501 exit signal Segmentation fault (11), possible coredump in /etc/apache2
[Wed Sep 18 18:13:53 2013] [notice] child pid 7506 exit signal Segmentation fault (11), possible coredump in /etc/apache2
[Wed Sep 18 18:14:14 2013] [notice] child pid 8708 exit signal Segmentation fault (11), possible coredump in /etc/apache2

I've tried to backtrace it by doing the following:

我试图通过执行以下操作来回溯它：

user:~$ sudo gdb
user     8670  8571  0 18:12 pts/3    00:00:00 grep --color=auto httpd
user:~$ sudo gdb

(gdb) attach 8571
Attaching to process 8571
Reading symbols from /bin/bash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libtinfo.so.5 
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libdl.so.2
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libc.so.6
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnss_compat.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_compat.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnsl.so.1
Reading symbols from /lib/x86_64-linux-gnu/libnss_nis.so.2...(no debugging symbols found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_nis.so.2
Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no debugging symbols      found)...done.
Loaded symbols for /lib/x86_64-linux-gnu/libnss_files.so.2
0x00007f553000244e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6

(gdb) backtrace
#0  0x00007f553000244e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x0000000000441419 in ?? ()
#2  0x000000000044255c in wait_for ()
#3  0x0000000000432c88 in execute_command_internal ()
#4  0x00000000004352fe in execute_command ()
#5  0x000000000041e31d in reader_loop ()
#6  0x000000000041ca87 in main ()

(gdb) backtrace full
#0  0x00007f553000244e in waitpid () from /lib/x86_64-linux-gnu/libc.so.6
No symbol table info available.
#1  0x0000000000441419 in ?? ()
No symbol table info available.
#2  0x000000000044255c in wait_for ()
No symbol table info available.
#3  0x0000000000432c88 in execute_command_internal ()
No symbol table info available.
#4  0x00000000004352fe in execute_command ()
No symbol table info available.
#5  0x000000000041e31d in reader_loop ()
No symbol table info available.
#6  0x000000000041ca87 in main ()
No symbol table info available.`

I can't make head or tale of the problem.

我无法理解这个问题。

I've also run gdb on apache as follows:

我还在 apache 上运行了 gdb，如下所示：

user:~$ sudo gdb apache2
Reading symbols from /usr/sbin/apache2...(no debugging symbols found)...done.

(gdb) run
Starting program: /usr/sbin/apache2
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
apache2: bad user name ${APACHE_RUN_USER}
[Inferior 1 (process 6925) exited with code 01]

I don't know if it's related to this issue but as soon as I installed gdb the following message is shown when I log in:

我不知道它是否与此问题有关，但是一旦我安装了 gdb，登录时就会显示以下消息：

=> There were exceptions while processing one or more plugins. See
 /var/log/landscape/sysinfo.log for more information.

sysinfo.log contains the following:

sysinfo.log 包含以下内容：

for process_info in info.get_all_process_info():
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 49, in get_all_process_info
process_info = self.get_process_info(process_id)
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 85, in get_process_info
process_info["state"] = STATES[state]
KeyError: 't (tracing stop)'
2013-09-18 18:43:35,633 ERROR    Processes plugin raised an exception.
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/landscape/sysinfo/sysinfo.py", line 99, in run
result = plugin.run()
File "/usr/lib/python2.7/dist-packages/landscape/sysinfo/processes.py", line 18, in run
for process_info in info.get_all_process_info():
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 49, in get_all_process_info
process_info = self.get_process_info(process_id)
File "/usr/lib/python2.7/dist-packages/landscape/lib/process.py", line 85, in get_process_info
process_info["state"] = STATES[state]
KeyError: 't (tracing stop)'

Some background.

一些背景。

I'm running a WordPress site off my VPS. The VPS is an Ubuntu based LAMP server with PERL and CURL installed. I use APC for caching but my segmentation faults occured before I installed APC. Finally I run my server throught Google PageSpeed Service so I have install the mod_remoteip mod for Apache 2.2 and have an X-Forwarded-For header in place.

我在我的 VPS 上运行一个 WordPress 网站。VPS 是一个基于 Ubuntu 的 LAMP 服务器，安装了 PERL 和 CURL。我使用 APC 进行缓存，但在安装 APC 之前发生了分段错误。最后，我通过 Google PageSpeed 服务运行我的服务器，所以我为 Apache 2.2 安装了 mod_remoteip mod 并有一个 X-Forwarded-For 标头。

ulimit core is unlimited. My phpinfo() file can be found here: http://tecne.ws/11v

ulimit 核心是无限的。我的 phpinfo() 文件可以在这里找到：http: //tecne.ws/11v

Please assist. It would be much appreciated!

请协助。将不胜感激！

回答by Bruce Aldridge

I had this issue and changed LogLevel warnto LogLevel debugin the apache config. On restart it seemed to be segfaulting just after mod_deflate.

我遇到了这个问题并在 apache 配置中更改LogLevel warn为LogLevel debug。在重新启动时，它似乎在 mod_deflate 之后出现了段错误。

Turning off mod_deflate in debian/ubuntu should just be sudo a2dismod deflate

在 debian/ubuntu 中关闭 mod_deflate 应该只是 sudo a2dismod deflate

回答by Jason

I solved this indirectly. I put Nginx in front of Apache and I no longer have segmentation errors. Having Nginx in front of Apache is a better set up in my opinion. Varnish Cache may have also solved the problem.

我间接解决了这个问题。我把 Nginx 放在 Apache 前面，我不再出现分段错误。在我看来，将 Nginx 放在 Apache 前面是一个更好的设置。Varnish Cache 可能也解决了这个问题。

回答by MitchellK

After an entire day of trying to trace this down, no solutions worked. I eventually however turned Apache to debug level logging and immediately noticed hundreds of notices/warnings with Google's mod_pagespeed for Apache trying to rewrite images from Jetpack's Photon images.

经过一整天的尝试追查，没有任何解决方案奏效。然而，我最终将 Apache 转向了调试级别的日志记录，并立即注意到 Google 的 mod_pagespeed for Apache 试图重写来自 Jetpack 的 Photon 图像的图像的数百个通知/警告。

I did a simple a2dismod pagespeedand no more segmentation faults.

我做了一个简单的a2dismod pagespeed并且没有更多的分段错误。

Have also noticed my sites are actually running faster now with mod pagespeed turned off.

还注意到我的网站现在实际上在关闭 mod pagespeed 的情况下运行得更快。

There seems to be quite a few bug reports about pagespeed causing segmentation faults.

似乎有很多关于页面速度导致分段错误的错误报告。

Not sure if its just mod_pagespeed or the combination of mod_pagespeed, wordpress and php .... but turned off now problem gone.

不确定它只是 mod_pagespeed 还是 mod_pagespeed、wordpress 和 php 的组合......但现在关闭问题消失了。

I am done with it for now and also in the process of moving everything to Nginx now. Tracing faults on Apache always turns into a nightmare, with Nginx I can find errors in a few seconds to a minute.

我现在已经完成了它，并且现在正在将所有内容移至 Nginx。在 Apache 上跟踪错误总是变成一场噩梦，使用 Nginx 我可以在几秒钟到一分钟内找到错误。

回答by user2047710

I was having the same issue with Varnish>Apache>PHP-FPM on Centos 6.

我在 Centos 6 上使用 Varnish>Apache>PHP-FPM 时遇到了同样的问题。

I solved it by disabling KeepAlive in Apache.

我通过在 Apache 中禁用 KeepAlive 解决了这个问题。

回答by dhh

In my case the error appeared, whenever I accessed my site from iOS / MacOS Safari. After the first access from one of those devices, apache kept craching with segmentation faults on any request from any device, until the next restart.

就我而言，每当我从 iOS / MacOS Safari 访问我的网站时，就会出现错误。从这些设备中的一个第一次访问后，apache 一直在对来自任何设备的任何请求进行分段错误，直到下一次重新启动。

The problem disappeared after disabling Google`s mod_spdymodule.

禁用 Google 的mod_spdy模块后问题消失。

回答by AnthonyB

This problem is often caused by an Apache module. As you can see, the other answers are about a module or another. The generic answer could be try to disable the last module(s) you enabled.

此问题通常是由 Apache 模块引起的。如您所见，其他答案与某个模块有关。通用答案可能是尝试禁用您启用的最后一个模块。

In my case, the module causing the problem is php7.3, on Ubuntu 18.04. PHP 7.2 works, but not PHP 7.3.

就我而言，导致问题的模块是 php7.3，在 Ubuntu 18.04 上。PHP 7.2 有效，但 PHP 7.3 无效。

回答by Elia Weiss

I tried to upgrade my system from ubuntu14.04 to 18.04, and got this issue, I downgrade to 16.04 to solve it.

我试图将我的系统从ubuntu14.04升级到 18.04，但遇到了这个问题，我降级到 16.04 来解决它。

I also upgrade my phpto 7.0

我也升级php到 7.0

回答by supersan

I was having this exact error and I just restarted the server (restarting apache didn't help).

我遇到了这个确切的错误，我只是重新启动了服务器（重新启动 apache 没有帮助）。

Might consider it if you've just done a apt upgrade

如果你刚刚做了一个，可能会考虑它 apt upgrade

回答by Markus Studer

Try to set

尝试设置

max_input_time = -1

max_input_time = -1

in your php.ini file.

在你的 php.ini 文件中。

from php.ini...

; Maximum amount of time each script may spend parsing request data. It's a good; idea to limit this time on productions servers in order to eliminate unexpectedly ; long running scripts. ; Note: This directive is hardcoded to -1 for the CLI SAPI ; Default Value: -1 (Unlimited) ; Development Value: 60 (60 seconds) ; Production Value: 60 (60 seconds) ; http://php.net/max-input-time;

从 php.ini ...

; Maximum amount of time each script may spend parsing request data. It's a good; idea to limit this time on productions servers in order to eliminate unexpectedly ; long running scripts. ; Note: This directive is hardcoded to -1 for the CLI SAPI ; Default Value: -1 (Unlimited) ; Development Value: 60 (60 seconds) ; Production Value: 60 (60 seconds) ; http://php.net/max-input-time;