我有一个至强E5504 2ghz和8GB内存的Hpnetworking服务器,使用freebsd 8.2-p9 amd64, nginx 1.2.1 , PHP 5.3.14 ,mysql 5.5.25,apc,memcached和其他软件包安装使用freebsd端口。 (在该消息结束时的conf文件)
我的麻烦很简单,我在/ var / log / messages中有很多“退出信号11”,当php-fpm子女死亡时,我的网站上有“502网关错误”,这真的很无聊,因为我已经在一天的很多错误,在这个php-fpm conf我已经强制它在一个沉重的configuration与150的PHP-FPM的孩子在静态模式下,pm.max_requests = 10000000,但在我的PHP-FPM日志我发现每个孩子:
[19-Jul-2012 18:58:14.666913] NOTICE: pid 84563, fpm_children_make(), line 421: [pool www] child 84717 started [19-Jul-2012 18:58:14.666984] DEBUG: pid 84563, fpm_event_loop(), line 409: event module triggered 1 events [19-Jul-2012 18:58:17.403217] DEBUG: pid 84563, fpm_event_loop(), line 409: event module triggered 2 events [19-Jul-2012 18:58:17.407442] DEBUG: pid 84563, fpm_got_signal(), line 72: received SIGCHLD [19-Jul-2012 18:58:17.407552] WARNING: pid 84563, fpm_children_bury(), line 252: [pool www] child 84563 exited on signal 11 (SIGSEGV) after 39.849444 seconds from start
并在同一个pid的/ var / log / message中:
Jul 19 18:58:14 web1 kernel: pid 84563 (php-fpm), uid 1001: exited on signal 11
可以肯定的是,这不是一个configuration文件(php.ini和php-fpm.conf)的麻烦,我恢复了它与我在档案中find的原始的一个,但没有,我试图使用spawn-fcgi,但同样的麻烦!
当我尝试生成一个运行“ gdb / usr / local / sbin / php-fpm ”的php-fpm.core时,当退出信号11时, php-fpm主进程退出,同时退出信号5核心转储) “(只有当我运行它扔GDB!),在这里日志和gdb回溯结果:
正如你在上一个链接中看到的,那是最后一行:
#659 0x0000000801534de0 in ?? () from /lib/libc.so.7 #660 0x0000000000000001 in ?? () #661 0x00007fffffffec08 in ?? () #662 0x000000000000000f in ?? () Cannot access memory at address 0x800000000000
有任何想法吗?
谢谢!
在/ var / log / messages中:
Jul 24 17:58:41 web1 kernel: pid 3887 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:42 web1 kernel: pid 3998 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:42 web1 kernel: pid 3895 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:42 web1 kernel: pid 3892 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:43 web1 kernel: pid 3889 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:43 web1 kernel: pid 3898 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:44 web1 kernel: pid 3886 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:44 web1 kernel: pid 3999 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:45 web1 kernel: pid 3896 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:45 web1 kernel: pid 4000 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:45 web1 kernel: pid 3893 (php-fpm), uid 1001: exited on signal 11 Jul 24 17:58:55 web1 kernel: pid 3885 (php-fpm), uid 0: exited on signal 5 (core dumped)
php.ini(仅与原始文件不同)
[PHP] memory_limit = 128M apc.enabled=1 apc.shm_size=128M apc.ttl=0 apc.mmap_file_mask=/tmp/apc/apc.XXXXXX error_reporting = E_ALL & ~E_DEPRECATED & ~E_NOTICE display_errors = On display_startup_errors = On track_errors = On html_errors = On upload_max_filesize = 4M [Date] date.timezone = Europe/Rome [browscap] browscap = /home/serverweb/etc/php/browscap.ini
php-fpm.conf(仅与原始文件不同)
[global] error_log = /home/serverweb/log/php-fpm/error.log log_level = debug emergency_restart_threshold = 10 emergency_restart_interval = 1m process_control_timeout = 10s process.max = 0 [www] user = web group = web listen = 127.0.0.1:9999 listen.allowed_clients = 127.0.0.1 pm = static pm.max_children = 16 pm.max_requests = 10000000 slowlog = /home/serverweb/log/php-fpm/$pool.log.slow
PHP 5.3.14有一个严重的错误 ,导致php-fpm中的段错误。 在5.3.15和5.4.5中被固定。
如果在最新版本的PHP中仍然存在,请尝试运行:
$ dmesg | grep segfault | tail -10 php-fpm[327]: segfault at 834ac30 ip 000000000834ac30 sp 00007ffc112d1b78 error 14 in libnss_nis-2.23.so[7fe02b461000+b000] php-fpm[329]: segfault at 834ac30 ip 000000000834ac30 sp 00007ffc112d1b78 error 14 php-fpm[331]: segfault at 834ac30 ip 000000000834ac30 sp 00007ffc112d2278 error 14 in libnss_nis-2.23.so[7fe02b461000+b000]
在行尾可以看到崩溃正在发生在哪个库中,例如
error 14 in libnss_nis-2.23.so
因此,您可以尝试升级该库,例如通过以下命令作为示例:
$ locate libnss_nis-2.23.so /lib/x86_64-linux-gnu/libnss_nis-2.23.so $ dpkg -S /lib/x86_64-linux-gnu/libnss_nis-2.23.so
然后根据哪个受影响的库属于,尝试升级。 如果没有帮助,请尝试search或报告相关的错误。
对于newrelic-X.so ,请参阅: PHP代理段错误 。
请注意,PHP 5.6及以下版本不再受支持。 请参阅: PHP支持的版本页面。 例如,PHP 5.6分支支持到2017年1月19日,所以build议将PHP升级到最近的稳定分支。
或者,当你不能升级你的版本时,启用和调查核心转储可能会指向崩溃根源的正确方向。