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
litespeed_wiki:php_503_error [2015/02/02 16:56]
Jackson Zhang [3. Enable Core Dump (or just turn off opcode caching)]
litespeed_wiki:php_503_error [2015/07/28 13:11]
Michael Alegre removed
Line 59: Line 59:
 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 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.
  
-Your Redhat/​Centos system may already use ABRT(Automatic Bug Reporting Tool) tool to generate core dump files. In this case, core file may be located at in /​var/​spool/​abrt/​. ​ ABRT configuration ​file is normally located at /etc/abrt/abrt.conf.  Please ​change ​the setting ​  "​ProcessUnpackaged = yes" in /​etc/​abrt/​abrt-action-save-package-data.conf to enable the core dump, otherwise ​it 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"​. ​+Your Redhat/​Centos system may already use ABRT(Automatic Bug Reporting Tool) tool to generate core dump files. In this case, core 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 dump, otherwise ​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]]. **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.
Line 145: Line 157:
   - Comment out the ''​extension_dir''​ line to let PHP pick a default.   - Comment out the ''​extension_dir''​ line to let PHP pick a default.
  
 +===== 7. lsphp process is killed unexpectedly =====
 +
 +when php script is executing, if the process is killed by admin or a process monitoring daemon, it'll simply result 503 error.
 +
 +An Example:
 +
 +A WHM/cPanel server, installed a plugin "​ConfigServer Security & Firewall"​(i.e.,​CSF / LFD), it killed lsphp5 process from time to time and result 503 error.
 +
 +/​etc/​csf/​csf.conf :
 +  # This User Process Tracking option sends an alert if any cPanel user process
 +  # exceeds the time usage set (seconds). To ignore specific processes or users
 +  # use csf.pignore
 +  #
 +  # Set to 0 to disable this feature
 +  PT_USERTIME = "​1800"​
 +  ​
 +so if lsphp5 process has run 1800 seconds(30 minutes), it might be caught by csf and killed. in php suExec Daemon mode or ProcessGroup mode, it's normal that the parent lsphp5 process keep running over 30 minutes. when csf/lfd kill lsphp5 process, it'll leave logs in /​var/​log/​lfd.log,​ like
 +
 +  Jun 19 16:29:16 evo lfd[18304]: *User Processing* PID:18264 Kill:1 User:xxxxx VM:538(MB) EXE:/​usr/​local/​lsws/​fcgi-bin/​lsphp-5.4.42 CMD:lsphp5
 +
 +the time stamp match 503 error in /​usr/​local/​apache/​logs/​error_log:​
 +
 +  2015-06-19 16:​29:​16.370 [NOTICE] [173.245.50.197:​61317-0#​APVH_pingje.org] oops! 503 Service Unavailable
 +
 +the fix:
 +
 +add
 +  pexe:/​usr/​local/​lsws/​fcgi-bin/​lsphp.*
 +to end of /​etc/​csf/​csf.pignore , then restart csf / lfd
 +  # csf -r
 +
 +or in WHM,
 +  Home » Plugins » ConfigServer Security & Firewall
 +  lfd - Login Failure Daemon
 +  "​csf.pignore,​ Process Tracking"​ Edit "lfd ignore file"
 +  append following line
 +  pexe:/​usr/​local/​lsws/​fcgi-bin/​lsphp.*
 +  "​Restart Lfd"
 +
 +===== 8. lsphp process hit memory limit =====
 +
 +when define a lsphp external application,​ there are 2 litespeed specific settings:
 +
 +  * Memory Soft Limit (bytes) (https://​www.litespeedtech.com/​docs/​webserver/​config/​extapps#​memSoftLimit)
 +  * Memory Hard Limit (bytes) (https://​www.litespeedtech.com/​docs/​webserver/​config/​extapps#​memHardLimit)
 +
 +As stated in the document: "The main purpose of this limit is to prevent excessive memory usage because of software bugs or intentional attacks, not to impose a limit on normal usage. Make sure to leave enough head room, otherwise your application may fail and 503 error may be returned."​
 +
 +so for example in a shared hosting server, with memory soft/hard limit set, if an php script in an account consumes too many memory, it'll fail(return 503 error) and other accounts are not affected. the ideal solution is to optimize the php script to consume less memory. A quick and temporary workaround is to raise the soft/hard limit to a big value(for example 8G), to see if the 503 error will be gone. here's a use case : https://​www.litespeedtech.com/​support/​forum/​threads/​solved-xenforo-rebuild-attachment-thumbnails-503.12403/​
 ====== Real World Examples ====== ====== Real World Examples ======