Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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.
Comment | File | Size | Author |
---|---|---|---|
#12 | 926426-system-check-http-request-deadlock.patch | 987 bytes | MustangGB |
#1 | 926426-system-check-http-request-deadlock.patch | 1.18 KB | Damien Tournoud |
Comments
Comment #1
Damien Tournoud CreditAttribution: Damien Tournoud commentedGood point.
I think we should hit a static file instead. Patch proposal attached.
Comment #2
mnicholas CreditAttribution: mnicholas commentedAs 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 ;-)
Comment #3
perusio CreditAttribution: perusio commentedI 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,
Comment #4
AntonioGM CreditAttribution: AntonioGM commentedI'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')
Comment #5
MustangGB CreditAttribution: MustangGB commentedPHP 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)
Comment #6
MustangGB CreditAttribution: MustangGB commentedHave tested this across 3 different sites and patch looks fine also
Comment #7
catch#1: 926426-system-check-http-request-deadlock.patch queued for re-testing.
Comment #9
perusio CreditAttribution: perusio commentedI 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...
Comment #10
MustangGB CreditAttribution: MustangGB commented#1: 926426-system-check-http-request-deadlock.patch queued for re-testing.
Comment #12
MustangGB CreditAttribution: MustangGB commentedRerolled
Comment #13
MustangGB CreditAttribution: MustangGB commentedPutting back to RTBC
Comment #14
catchThis is a duplicate of #965078: HTTP request checking is unreliable and should be removed in favor of watchdog() calls.