I'm using Drupal 7. I get this error when I change the pagination offset. I thought it was a memory issue so I increased PHP memory limit but that didn't work.
It doesn't happen on all the pages. It happens on page 2.
The pages are created with a paginated view.
http://s***.build.us.*****.net/ko/learning-center/blog?page=2 //this doesn't work
but not on page 3
http://s***.build.us.*****.net/ko/learning-center/blog?page=3 . //this works
There is nothing useful in the apache access or the error log
When I use drush I get the following
Command watchdog-show needs a higher bootstrap level to run - you will need to invoke drush from a more functional Drupal environment to run this command. [error]
The drush command 'watchdog-show' could not be executed.
Error 500 means there was a Fatal Error in a PHP script. You could try to check Drupal Log files. It could be a bug with Drupal itself.
The issue was mysql
i had to increase the mysql config directive
mysql max_allowed_packet to something higher
Related
I am getting a blank screen and nothing in the error logs for a php program I am trying to get up and running (it happens to be yourls). What do I need to do to get error logging enabled or to otherwise get an indicate of why the page is not loading (I know there are multiple postings on this but none of the fixes suggested in this posts seems to generate any output and don't seem to work for this specific implementation)?
I'm running php from this install: php-8.0.0-nts-Win32-vs16-x64.zip
I'm running Apache HTTPD from this install: httpd-2.4.46-o111i-x64-vc15.zip
Turns out this was a behavior of the yourls software I was trying to run. It had a flag that turned error logging/messaging off AND it was not compatable with php 8. I switched to php 7 and switched to the php.ini-development config (by renaming it to php.ini) and I am now seeing error messages (the driver for the database is missing).
We have setup a Wordpress Website on IIS 10 which was working fine. But suddenly it stops working and i got this error
"FASTCGI process has failed frequently recently. Try the request again
in a while"
Restarting IIS fixed this problem.
Anybody tell me why this issue has occurred and how we can fix this ?
Thanks
Open command prompt as administrator and navigate to the php-cgi.exe
folder.
Execute any PHP file from your application to know the exact error. In my case, I created a simple phpinfo.php page and executed
following command.
C:\Program Files (x86)\PHP\v7.4.5>php-cgi.exe E:\Websites\mysite\phpinfo.php
It showed me the exact error saying 'vcruntime140.dll is not
compatible with this PHP build' & I have updated to 'Microsoft Visual C++ Redistributable for Visual Studio 2019'. You can download it from here.
Once you identified and resolved the error(point 3), you need to restart IIS server and run your website. It will work as expected.
If you're running PHP 8 turn track_errors Off in php.ini . Track_errors have been deprecated since 7.2 and can cause a fatal error in IIS
Finally, i found the solution to the issue, It is due to the low value given to "Rapid Fails PerMinute" - see above image posted by German Martin.
From Microsoft's website the default value for "Rapid Fails PerMinute" is 90 but i reduced it 10 and then the error "FASTCGI process has failed frequently recently...." started showing up.
Once i set it back to the default value of 90 , the error stopped. This is what worked for me, in my case.
You need to maximize "Instance MaxRequest" at FASTCGI Configuration. Just clic en IIS root -> FastCGI Settings, select you php-cgi.exe for WP and clic Edit. Then increise Instance MaxRequests
[IIS FastCGI Settings]
We are having issues with our staging machine, which is running Magento EE 1.13.1
The problem started happening Tuesday afternoon.
At that time we updated an installed php / mysql application.
On the main magento site, the browser is redirected to the magento install page.
The problem occurs only within the Magento application and is related to sessions – when the error occurs, magento throws a fatal similar to this:
(I created a small test application to try to isolate the problem).
Fatal error: Call to a member function getCode() on a non-object in /var/www/html/app/code/core/Mage/Customer/Model/Session.php on line 71
Call Stack: 0.0002 653728
1. {main}() /var/www/html/t.php:0 0.3013 8153600
2. Mage::getSingleton() /var/www/html/t.php:20 0.3013 8153912
3. Mage::getModel() /var/www/html/app/Mage.php:477 0.3013 8153912
4. Mage_Core_Model_Config->getModelInstance() /var/www/html/app/Mage.php:463 0.3016 8302032
5. Mage_Customer_Model_Session->__construct() /var/www/html/app/code/core/Mage/Core/Model/Config.php:1348
The issue only occurs intermittently, and we can temporarily fix it by stopping and starting the httpd service.
We are running magento ee 1.13.1, php 5.3.3, and httpd 2.2.15
This is happening on a staging machine. Our production machine which has the same system and code on it, it working correctly.
We have tried to turn on/off magento compiling, caching, php apc, changed the php sessions to use the disk rather than /tmp/fs, and changed magento to use the DB for its sessions.
The site fails after several minutes.
There are no errors in the system logs.
Can someone suggest how to debug this?
This turned out to be an issue related to the libxml_disable_entity_loader() function.
The zend framework calls this function libxml_disable_entity_loader(true) and then calls it again with (false).
There is a path through our code that was leaving this set to true.
This setting's scope is not limited to the current php script, but to the current httpd process. I.e. it's sticky, and this prevents php's simplexml_load_file function from loading external files.
I came across this article:
Intermittent simplexml_load_file(): I/O warning on local Joomla site
Which led me discover that libxml_disable_entity_loader is not thread safe, and indeed 'sticky' within httpd processes.
Disable Magento compilation:
$ php -f shell/compiler.php -- disable
Compiler include path disabled
There are three ways in which this can be done:
From Magento admin
Navigate to System → Tools → Compilation page and click on Disable button. Navigate to System → Cache Management screen and use Flush Cache button.
Using SFTP, by editing at includes/config.php file
To disable compilation in Magento, edit includes/config.php. Uncomment the first line and comment out the second:
define('COMPILER_INCLUDE_PATH', dirname(FILE).DIRECTORY_SEPARATOR.'src');
define('COMPILER_COLLECT_PATH', dirname(FILE).DIRECTORY_SEPARATOR.'stat');
Using SSH shell program:
php -f shell/compiler.php -- disable
php -f shell/compiler.php -- clear
i got a script which creates a list implementation of messages being sent between users.
Everything works fine, till the amount of messages rises up to about 77.000.
For every message a object will be created and every object has a reference to the next message object.
I enabled error reporting and increased the memory limit - I don't get any errors and the http status code is a 200 Ok, even if the developer console tells me that the request failed.
If you have verified that it is not a memory limit issue, this could be a limitation of PHP....similar to this question:
How to Avoid PHP Object Nesting/Creation Limit?
If you need to work with 77 000 objects in the same PHP script - it is something wrong with the architecture, php is not right choice for such calculations (even if it can handle this under some circumstances)
to track this particular error try to set in php.ini:
display_errors=1
display_startup_errors=1
error_reporting=-1
log_errors=1
memory_limit=to any reasonable value
max_input_time=to any reasonable value
max_execution_time=to any reasonable value
report_memleaks=1
error_log=writable path
consider using xdebug extension
don't forget to restart apache after changing proper php.ini (you can have different php.ini for apache and cli)
check if any set_error_handler or set_exception_handler functions are called in your code
I was wondering if anybody knew of a method to configure apache to fall back to returning a static HTML page, should it (Apache) be able to determine that PHP has died? This would provide the developer with a elegant solution to displaying an error page and not (worst case scenario) the source code of the PHP page that should have been executed.
Thanks.
The PHP source code is only displayed when apache is not configured correctly to handle php files. That is, when a proper handler has not been defined.
On errors, what is shown can be configured on php.ini, mainly the display_errors variable. That should be set to off and log_errors to on on a production environment.
If php actually dies, apache will return the appropriate HTTP status code (usually 500) with the page defined by the ErrorDocument directive. If it didn't die, but got stuck in a loop, there is not much you can do as far as I know.
You can specify a different page for different error codes.
I would assume that this typically results in a 500 error, and you can configure apaches 500 handler to show a static page:
ErrorDocument 500 /500error.html
You can also read about error handlers on apaches documentation site
The real problem is that PHP fatal errors don't cause Apache to return a 500 code. Errors except for E_FATAL and E_PARSE can be handled however you like using set_error_handler().
There are 2 ways to use PHP and Apache.
1. Install PHP as an Apache module: this way the PHP execution is a thread inside the apache process. So if PHP execution fails, then Apache process fails too. there is no fallback strategy.
2. Install PHP as a CGI script handler: this way Apache will start a new PHP process for each request. If the PHP execution fails, then Apache will know that, and there might be a way to handle the error.
regardless of the way you install PHP, when PHP execution fails you can handle errors in the php.ini file.