开发学院 WEB开发 PHP 关于php-cgi 的 SIGSEGV 错误的一些想法阅读

关于php-cgi 的 SIGSEGV 错误的一些想法

　2009-07-03 09:23:41　来源：WEB开发网　闂傚倸鍊搁崐鎼佸磹妞嬪孩顐芥慨姗嗗厳缂傛氨鎲稿鍫罕闂備礁婀遍搹搴ㄥ窗閺嶎偆涓嶆い鏍仦閻撱儵鏌ｉ弴鐐测偓鍦偓姘炬嫹

闂傚倸鍊搁崐鎼佸磹妞嬪海鐭嗗〒姘ｅ亾妤犵偛顦甸弫鎾绘偐閹绘帞鈧參姊哄Ч鍥х仼闁诲繑鑹鹃悾鐑藉蓟閵夛妇鍘甸梺瑙勵問閸犳牠銆傛總鍛婄厱閹艰揪绱曟牎闂侀潧娲ょ€氫即鐛幒妤€绠ｆ繝闈涘暙娴滈箖鏌ｉ姀鈶跺湱澹曟繝姘厵闁绘劦鍓氶悘杈ㄤ繆閹绘帞澧涚紒缁樼洴瀹曞崬螖閸愬啠鍓濈换娑樼暆婵犱胶鏁栫紓浣介哺閹瑰洤鐣烽幒鎴僵闁瑰吀鐒﹂悗鎼佹⒒娴ｇ儤鍤€闁搞倖鐗犻獮蹇涙晸閿燂拷

濠电姷鏁告慨鐑藉极閸涘﹥鍙忔い鎾卞灩缁狀垶鏌涢幇闈涙灈鐎瑰憡绻冮妵鍕箻鐎靛摜鐣奸梺纭咁潐濞茬喎顫忕紒妯肩懝闁逞屽墮宀ｈ儻顦查悡銈夋煏閸繃鍋繛宸簻鎯熼梺瀹犳〃閼冲爼宕濋敃鈧—鍐Χ閸℃鐟愰梺鐓庡暱閻栧ジ宕烘繝鍥у嵆闁靛骏绱曢崢顏堟⒑閹肩偛鍔楅柡鍛⊕缁傛帟顦寸紒杈ㄥ笚濞煎繘鍩℃担閿嬵潟闂備浇妗ㄩ悞锕傚箲閸ヮ剙鏋侀柟鍓х帛閺呮悂鏌ㄩ悤鍌涘闂傚倸鍊搁崐鎼佸磹妞嬪孩顐芥慨姗嗗厳缂傛氨鎲稿鍫罕闂備礁婀遍搹搴ㄥ窗閺嶎偆涓嶆い鏍仦閻撱儵鏌ｉ弴鐐测偓鍦偓姘炬嫹　　闂傚倸鍊搁崐鎼佸磹閻戣姤鍤勯柤鍝ユ暩娴犳氨绱撻崒娆掑厡缂侇噮鍨堕妴鍐川閺夋垹鍘洪悗骞垮劚椤︻垶宕￠幎鑺ョ厪闊洦娲栨牎闂佽瀵掗崜鐔奉潖閾忓湱纾兼俊顖氭惈椤秴顪冮妶鍡楀闁告鍥х叀濠㈣泛谩閻斿吋鐓ラ悗锝庡厴閸嬫挻绻濆顓涙嫼閻熸粎澧楃敮鎺撶娴煎瓨鐓曢柟鎯ь嚟閳藉鏌嶇紒妯荤叆妞ゎ偅绻堥幊婊呭枈濡顏归梻鍌欑閹诧紕绮欓幋锔哄亼闁哄鍨熼弸鏃堟煛閸愶絽浜剧紓浣虹帛缁嬫挻绂掗敃鍌氱＜婵﹩鍓﹂悗鎶芥⒒娴ｅ摜锛嶇紒顕呭灦楠炴垿宕堕鍌氱ウ闁诲函缍嗘禍鏍绩娴犲鐓欓梺顓ㄧ畱婢ь垱銇勯弬鍨偓瑙勭┍婵犲洦鍊锋い蹇撳閸嬫捇寮借濞兼牕鈹戦悩瀹犲闁稿被鍔庨幉姝岀疀濞戞ḿ鐤呴梺鍦檸閸犳寮查幖浣圭叆闁绘洖鍊圭€氾拷

核心提示：几台使用了 nginx+php-fpm 的机器上，偶尔能看到php-fpm.log中有这样的内容引用Oct 28 23:13:53.849419 [NOTICE] fpm_got_signal(), line 73: received SIGCHLDOct 28 23:13:53.849490 [WARNING] fp

几台使用了 nginx+php-fpm 的机器上，偶尔能看到php-fpm.log中有这样的内容

引用
Oct 28 23:13:53.849419 [NOTICE] fpm_got_signal(), line 73: received SIGCHLD
Oct 28 23:13:53.849490 [WARNING] fpm_children_bury(), line 229: child 15044 (pool default) exited on signal 11 SIGSEGV after 1.332818 seconds
Oct 28 23:13:53.850341 [NOTICE] fpm_children_make(), line 305: child 15122 (pool default) started

如果得到SIGSEGV信号的进程比较多的话，还能看到如下的日志

引用
Oct 28 09:03:15.812009 [WARNING] fpm_children_bury(), line 256: failed PRocesses threshold (10 in 60 sec) is reached, initiating reload
Oct 28 09:03:15.812030 [NOTICE] fpm_pctl(), line 208: switching to 'reloading' state

然后php-fpm就会重启。其中的
failed processes threshold (10 in 60 sec) is reached
是在php-fpm.conf中设置的，表示在60秒内出现SIGSEGV或者SIGBUS错误的php-cgi进程数如果超过10个，php-fpm就会重启。可以通过把php-fpm.conf中的 emergency_restart_threshold的值设置的大一些来增加这个重启的阀值，比如增加到60个，在有些时候，这能够避免php-fpm重启，但这并不是解决问题的根本办法

SIGSEGV信号一般表示

引用
SIGSEGV --- Segment Fault. The possible cases of your encountering this error are:
1.buffer overflow --- usually caused by a pointer reference out of range.
2.stack overflow --- please keep in mind that the default stack size is 8192K.
3.illegal file access --- file Operations are forbidden on our judge system

其中的第三条，跟本问题的关系比较大。也就是php-cgi访问了一个不存在的或者没有权限访问的文件
我用的php-fpm补丁是0.5.8版的，按照一些说法，只要设置了

引用
fastcgi_param SCRipT_NAME　　　 $fastcgi_script_name;

之后，php-cgi如果找不到文件或者没有权限访问的话会提示No input file specified. 或者Access denied.
问题到这里似乎又陷入了僵局
后来又在php.ini中找到了php-cgi的一个参数 cgi.fix_pathinfo

引用
cgi.fix_pathinfo boolean
对 CGI 提供了真正的 PATH_INFO/PATH_TRANSLATED 支持。以前 PHP 的行为是将 PATH_TRANSLATED 设为 SCRIPT_FILENAME，而不管 PATH_INFO 是什么。有关 PATH_INFO 的更多信息见 cgi 规格。将此值设为 1 将使 PHP CGI 修正其路径以遵守规格。设为 0 将使 PHP 的行为和从前一样。默认为零。用户应该修正其脚本使用 SCRIPT_FILENAME 而不是 PATH_TRANSLATED。

把这个参数的值设置为1 ，cgi会多做一些检查，来判断请求的路径中，那部分是文件名，哪部分是路径名
下面是google groups上的一段话

引用
when cgi.fix_pathinfo was set to "1" it caused a lot of checks in order to find which part of SCRIPT_FILENAME is a file name and which is PATH_INFO. In case of missing file it caused NULL
in path_translated, which caused the crash.

此问题已经耗费了我太多的精力，已经不愿意多花时间去查问题了。比如，可以使用gbd来查看php-cgi 出错以后产生的dump文件。但这个问题只是偶尔发生，很难捕捉到。如果有兄弟也遇到这个问题，或者你有更好的解决办法，不妨大家交流一下
修改此参数后，观察了一段时间，SIGSEGV错误在一些服务器上确实消失了。
补充一下 11月10日早上6点半左右到9点26分，三台服务器(给校内网做的app)同时出现了大量的SIGSEGV错误，校内的服务器出的故障，在我这几台服务器上产生了大量的不正确的 post / ，后来问校内的工程师，他们只说服务down掉了，却不肯略微详细的说一下情况。后来我模拟这些post，确没出问题？？奇怪了