Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revision Both sides next revision
litespeed_wiki:php_503_error [2014/07/15 19:57]
Michael Armstrong
litespeed_wiki:php_503_error [2015/02/27 16:07]
Jackson Zhang [3. Enable Core Dump (or just turn off opcode caching)]
Line 55: Line 55:
 If you find that PHP has crashed (as demonstrated by the process being "​killed by signal"​),​ a core dump will allow you to look further into the cause of the crash. If you find that PHP has crashed (as demonstrated by the process being "​killed by signal"​),​ a core dump will allow you to look further into the cause of the crash.
  
-To enable a core dump, add the environment value ''​LSAPI_ALLOW_CORE_DUMP=1'' ​to your external application settings (WebAdmin console > Configuration > External App). Next time the application crashes, a core dump will be generated. The core file created can usually be found in the directory holding the PHP script affected.+To enable a core dump, add the environment value  
 +  ​LSAPI_ALLOW_CORE_DUMP=1 ​ 
 +to your external application settings (WebAdmin console > Configuration > External App). Next time the application crashes, a core dump will be generated. The core file created can usually be found in the directory holding the PHP script affected.
  
-**Note:** As noted belowopcode caches ​are frequently a cause of PHP crashesIf you find your PHP crashedyou may want to try turning off any opcode caching you have. This is addressed further [[litespeed_wiki:​php_503_error#​opcode_caches_apc_xcache_eaccelerateor|below]].+Your Redhat/​Centos system may already use ABRT(Automatic Bug Reporting Tool) tool to generate core dump files. In this casecore files may be located at /​var/​spool/​abrt/​. ​ ABRT configuration files are normally located at /etc/abrt/ ​Please ensure the setting ​  "​ProcessUnpackaged = yes" in /​etc/​abrt/​abrt-action-save-package-data.conf to enable the core dumpotherwise core file may not be generated even the web server error log says so.  If you want to disable core file dump after the debugging, simply change "​ProcessUnpackaged"​ setting back to "​no"​
  
 +core_pattern is used to specify a core dumpfile pattern name. 
 +  cat /​proc/​sys/​kernel/​core_pattern
 +which shows you the pattern template for the output filename.
 +
 +If the first character of the pattern is a '​|',​ the kernel will treat the rest of the pattern as a command to run.  The core dump will be written to the standard input of that program instead of to a file. 
 +
 +By default, /​proc/​sys/​kernel/​core_pattern contains core string and kernel produces core.* files in crashed process'​s current directory.
 +
 +Abrt’s C/C++ hook overrides this with:
 +  |/​usr/​libexec/​abrt-hook-ccpp %s %c %p %u %g %t e
 +which results in kernel calling abrt-hook-ccpp
 +
 +**Note:** As noted below, opcode caches are frequently a cause of PHP crashes. If you find your PHP crashed, you may want to try turning off any opcode caching you have. This is addressed further [[litespeed_wiki:​php_503_error#​opcode_caches_apc_xcache_eaccelerateor|below]].
 ===== 4. Analyze Core File with GNU Debugger =====  ===== 4. Analyze Core File with GNU Debugger ===== 
  
-GNU Debugger (GDB) uses the syntax ''​gdb <​path/​to/​lsphp/​binary>​ <​path/​to/​core/​file>''​. (Your LSPHP binary can usually be found in ''/​usr/​local/​lsws/​fcgi-bin''​.)+GNU Debugger (GDB) uses the syntax ''​gdb <​path/​to/​lsphp/​binary>​ <​path/​to/​core/​file>''​. (Your LSPHP binary can usually be found in ''/​usr/​local/​lsws/​fcgi-bin''​. ​If you installed LSPHP through LiteSpeed Repository, LSPHP binary file usually locates in ''/​usr/​local/​lsws/​lsphp5x/​lsphp''​('​x'​ means PHP version of '​3'​ '​4'​ '​5'​ or '​6'​) ​)
  
 Once you have opened the core file with GDB, use ''​bt''​ command to print a backtrace of the stack (the steps that the process application took coming to the crash). This will often reveal what caused the crash. Once you have opened the core file with GDB, use ''​bt''​ command to print a backtrace of the stack (the steps that the process application took coming to the crash). This will often reveal what caused the crash.