Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
|
litespeed_wiki:php:503-errors [2018/07/24 18:08] Jackson Zhang |
litespeed_wiki:php:503-errors [2018/09/14 16:05] Michael Alegre [The lsphp process is killed unexpectedly by CSF/LFD] |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| ====== Troubleshooting 503 Errors ====== | ====== Troubleshooting 503 Errors ====== | ||
| - | 503 errors are often caused by a malfunction in PHP, not apache or LiteSpeed web server. The one of the common reason is due to PHP crash. Generally troubleshooting 503 errors is out of our support scope. | + | 503 errors are often caused by a malfunction in PHP, and are not related to Apache or LiteSpeed Web Server. One of the common reasons for a 503 error is a PHP crash. Generally, troubleshooting 503 errors is out of our support scope. Just the same, this wiki will go over basic steps to troubleshoot 503 errors, some common causes of 503 errors, and some examples that show the steps in practice. |
| - | If your server is running on a control panel such as cpanel/plesk and runs into 503 error, you should temporarily switch to apache for a test. Most of the time, it will run into the same 503 issue with Apache. It means it is not LiteSpeed web server issue and you may try the following steps to resolve it. If it runs well with apache but 503 problems only with LiteSpeed, you can log a ticket with us to take a look. | + | If your server is running on a control panel, such as cPanel or Plesk, and runs into a 503 error, you should temporarily switch to Apache for a test. Most of the time, it will run into the same 503 issue with Apache. This means that it is //not// a LiteSpeed Web Server issue. Nonetheless, we have provided this wiki to give you some troubleshooting ideas. Please run through the steps outlined below until you find the issue. |
| - | This wiki will go over basic steps to troubleshoot 503 errors, some common causes of 503 errors, and some examples that show the steps in practice. | + | **If everything runs well with Apache but 503 problems occur only with LiteSpeed, you can log a ticket with us to take a look.** |
| - | If the troubleshooting steps sound too overwhelming to you, you can engage us through hourly support and we will troubleshoot and try our best to fix the issue for you. Please order 1-hour support through https://store.litespeedtech.com/store/cart.php?gid=5 . | + | If these troubleshooting steps sound too overwhelming to you, you can engage us through [[https://store.litespeedtech.com/store/cart.php?gid=5|hourly support]]. We will troubleshoot and try our best to fix the issue for you. |
| - | + | ||
| - | Before engaging us for premium support service, you may like to try a few simple steps in Quick Troubleshooting Guide below to see if you can fix the error yourself. | + | |
| ===== Quick Troubleshooting Guide ===== | ===== Quick Troubleshooting Guide ===== | ||
| + | Before engaging us for premium support service, you may like to try a few of these simple steps to see if you can fix the error yourself. | ||
| + | |||
| * Check the phpinfo page of the problematic user account. ([[litespeed_wiki:php:php_info|Create a phpinfo.php file]] if no phpinfo page exists.) | * Check the phpinfo page of the problematic user account. ([[litespeed_wiki:php:php_info|Create a phpinfo.php file]] if no phpinfo page exists.) | ||
| * Generally, server ''error_log/stderr.log'' should provide some hints as to the problem. For example, it may be a memory issue. | * Generally, server ''error_log/stderr.log'' should provide some hints as to the problem. For example, it may be a memory issue. | ||
| Line 21: | Line 21: | ||
| * Try increasing the PHP memory limit. | * Try increasing the PHP memory limit. | ||
| - | The above list outlines a few simple steps for you to try first. These are just partial PHP 503 error quick fixes. You can refer to the following for detailed steps/reasons. | + | These are just a few simple quick fixes for you to try first. If they don't help, you can refer to the following for detailed steps/reasons, or engage our support as mentioned earlier. |
| ===== Comprehensive Troubleshooting Guide ===== | ===== Comprehensive Troubleshooting Guide ===== | ||
| Line 239: | Line 239: | ||
| Check the PHP ''max_execution_time'' configuration in a phpinfo() page to see if it is set high enough to handle long running requests. | Check the PHP ''max_execution_time'' configuration in a phpinfo() page to see if it is set high enough to handle long running requests. | ||
| - | ====The lsphp process is killed unexpectedly by CSF/LFD ==== | + | ==== The lsphp process is killed unexpectedly by CSF/LFD ==== |
| - | When a php script is executing, if the process is killed by the admin or a process monitoring daemon, it'll result in 503 errors. | + | When a PHP script is executing, if the process is killed by the admin or a process monitoring daemon, it'll result in 503 errors. |
| === CSF/LFD Kill === | === CSF/LFD Kill === | ||
| Line 255: | Line 255: | ||
| PT_USERTIME = "1800" | PT_USERTIME = "1800" | ||
| | | ||
| - | So if an 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 keeps running after 30 minutes. When csf/lfd kills an lsphp5 process, it'll leave logs in ''/var/log/lfd.log''. These logs will look similar to the following: | + | So if an lsphp5 process has run 1800 seconds (30 minutes), it might be caught by csf and killed. In PHP Daemon mode or ProcessGroup mode, it's normal that the parent lsphp5 process keeps running after 30 minutes. When csf/lfd kills an lsphp5 process, it'll leave logs in ''/var/log/lfd.log''. These logs will look similar to the following: |
| 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 | 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 | ||
| Line 321: | Line 321: | ||
| ==== Magento 503 error ==== | ==== Magento 503 error ==== | ||
| - | After (re)installation of LiteMage Cache extension in Magento Connect manager, Magento site couldn't be accessed and may give 503 errors. Please refer [[litespeed_wiki:cache:litemage:troubleshooting:connect-cache-session-cleaning-error|this]] for details. | + | After (re)installation of LiteMage Cache extension in Magento Connect manager or enable other modules in Magento 2, Magento site may be placed in maintenancence mode and couldn't be accessed and may give 503 errors. Please refer [[litespeed_wiki:cache:litemage:troubleshooting:connect-cache-session-cleaning-error|this]] for details. |
| ===== Advanced Troubleshooting Guide ===== | ===== Advanced Troubleshooting Guide ===== | ||
| - | The above comprehensive guide list the most cases which might lead to 503 errors. In some circumstance, it could be very difficult to locate the root cause of the errors. If PHP crashs, you can enable core dump and use gdb to debug the core file. You will need to be clear that even you find some PHP internal bug which caused the crash, there are limited thing you can do other than disabling that module or change to other php version which may not have such bug. Reporting bug to PHP could be an option but you may not get a solution in a very short timeframe. | + | The above comprehensive guide lists the most likely cases which might lead to 503 errors. In some circumstances, it could be very difficult to locate the root cause of the errors. If PHP crashes, you can enable a core dump and use gdb to debug the core file. You will need to be clear that even if you find some internal PHP bug which has caused the crash, there are limited things you can do about it. You can disable the module or change to another PHP version which may not have such a bug. Reporting the bug to PHP could be an option, but you may not get a solution in a timely manner. |
| - | If there is on core file generated and tried all the above mothods but still have not reached a solution, you can try to strace PHP process to find out hint. Just be prepared that strace log could be very very long and overwheming, you may need some experience and knowledge to understand what they mean and hopefully can locate the right section of the problem from the log. | + | If there is a core file generated and you've tried all of the above methods without reaching a solution, you can try to strace the PHP process for a hint. Just be prepared that the strace log could be very very long and overwhelming. You likely need some experience and knowledge to understand what the log entries mean and it can be a challenge even to locate the relevant section of the log. |
| ==== Strace the PHP process ==== | ==== Strace the PHP process ==== | ||
| Line 348: | Line 348: | ||
| strace -tt -T -f -p 791228 | strace -tt -T -f -p 791228 | ||
| + | Sometimes, it may not be easy to get the ''pid'' since the PHP may run very quickly. In this case, you can try to strace the //parent pid//, but the disadvantage of stracing the parent pid is that you may get too much unrelated information in strace log. That would make it difficult to locate the problem pattern. | ||
| + | One solution is to use a script to catch the pid. It depends on which SuEXEC user your PHP will be running and which script will be running ( such as index.php etc). | ||
| + | | ||
| + | while true; do if mypid=`ps aux | grep $USERNAME | grep lsphp | grep $SCRIPTNAME | grep -v grep | awk '{print $2; }' | tail -1`; then strace -tt -T -f -p $mypid; fi ; done | ||
| + | |||
| + | **Note**: ''$USERNAME'' should be replaced with a real username; ''$SCRIPTNAME'' should be replaced by the name of the script that is running, such as ''index.php'' or other scripts. | ||
| ==== Enable Core Dump ==== | ==== Enable Core Dump ==== | ||
| Line 417: | Line 423: | ||
| This backtrace shows us that the program crashed soon after accessing the opcode cache. This suggests that the issue is with the opcode cache. The user can then try upgrading the opcode cache or changing their PHP version. If neither of those work, the user should try to disable the opcode cache. | This backtrace shows us that the program crashed soon after accessing the opcode cache. This suggests that the issue is with the opcode cache. The user can then try upgrading the opcode cache or changing their PHP version. If neither of those work, the user should try to disable the opcode cache. | ||
| - | + | ===== Real World Examples ===== | |
| - | + | ||
| - | ====== Real World Examples ====== | + | |
| [[litespeed_wiki:php:503-errors:example-1|Bad Directive in php.ini]] | [[litespeed_wiki:php:503-errors:example-1|Bad Directive in php.ini]] | ||