Posted by mnicholas on September 29, 2010 at 3:00pm
9 followers
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | system.module |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (duplicate) |
| Issue tags: | needs backport to D7 |
Issue Summary
Since system_check_http_request() makes a call to itself, a 1-child FastCGI server becomes deadlocked; Lighttpd may also do the same.
The script times out after 30s, a value set in drupal_http_request().
The workaround is to have two or more children running for FastCGI.
Comments
#1
Good point.
I think we should hit a static file instead. Patch proposal attached.
#2
As has been (much) discussed previously: http://drupal.org/node/227791, http://drupal.org/node/245853 & http://drupal.org/node/245990; this test proves very little as the request never "leaves the building" as it were. Better to do an update check with drupal.org perhaps and then report accordingly. This could be useful even during an install, as Drupal could flag to the user that the version being installed is out-of-date. You'll have to allow for poor Debian users who will always be installing an out-of-date version ;-)
#3
I don't think that this is a Drupal issue per se. Instead it seems to be a problem of php FastCGI config.
1. How many children does the process spawns?
2. Does it auto-spawn?
3. Is there any supervision of the php-cgi process?
I'm running php 5.2.12 on a mixed Debian Testing/Unstable and everyhting is snappy with just 4 children. Here's my php-cgi init script. I use monit to supervise the process.
HTH,
#4
I'm experiencing the same problem:
- Drupal 7.2
- Apache/2.2.19 (Win32) PHP/5.2.17 using mod_php.
This causes an empty Configuration page on the Admin menu, hiding all errors.
This is the stack trace when the script execution timeouts:
_drupal_error_handler()
@stream_socket_client() --> Timeous at the same time
drupal_http_request()
system_check_http_request()
system_requirements('runtime')
module_invoke_all('requirements', 'runtime')
system_status(TRUE)
system_admin_config_page()
menu_execute_active_handler('admin/config')
#5
PHP FastCGI under Windows doesn't support multiple children so I couldn't try that
However Damien Tournoud solution works perfectly (tested with nginx 1.1.4)
#6
Have tested this across 3 different sites and patch looks fine also
#7
#1: 926426-system-check-http-request-deadlock.patch queued for re-testing.
#8
The last submitted patch, 926426-system-check-http-request-deadlock.patch, failed testing.
#9
I believe that the best option to make this function fast is to request a 1x1 GIF transparent that resides in memory. Yes it requires persistence. But in the other hand it's fast and safe. See Nginx empty GIF module. If I gave some thought to this would such a patch would make it to core?
Where available it would use APC or memcache to store the 1x1 transparent GIF, to keep it across requests without intervention of the DB. A fast, small chunk of data that functions as an heartbeat for the drupal site. Just an idea...
#10
#1: 926426-system-check-http-request-deadlock.patch queued for re-testing.
#11
The last submitted patch, 926426-system-check-http-request-deadlock.patch, failed testing.
#12
Rerolled
#13
Putting back to RTBC
#14
This is a duplicate of #965078: HTTP request checking is unreliable and should be removed in favor of watchdog() calls.