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.

Files: 
CommentFileSizeAuthor
#12 926426-system-check-http-request-deadlock.patch987 bytesakamustang
PASSED: [[SimpleTest]]: [MySQL] 34,273 pass(es).
[ View ]
#1 926426-system-check-http-request-deadlock.patch1.18 KBDamien Tournoud
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 926426-system-check-http-request-deadlock.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Comments

Version:7.0-alpha7» 7.x-dev
Status:Active» Needs review
StatusFileSize
new1.18 KB
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch 926426-system-check-http-request-deadlock.patch. Unable to apply patch. See the log in the details link for more information.
[ View ]

Good point.

I think we should hit a static file instead. Patch proposal attached.

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 ;-)

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,

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')

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)

Status:Needs review» Reviewed & tested by the community

Have tested this across 3 different sites and patch looks fine also

Status:Reviewed & tested by the community» Needs work

The last submitted patch, 926426-system-check-http-request-deadlock.patch, failed testing.

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...

Status:Needs work» Needs review

Status:Needs review» Needs work

The last submitted patch, 926426-system-check-http-request-deadlock.patch, failed testing.

Version:7.x-dev» 8.x-dev
Status:Needs work» Needs review
Issue tags:+needs backport to D7
StatusFileSize
new987 bytes
PASSED: [[SimpleTest]]: [MySQL] 34,273 pass(es).
[ View ]

Rerolled

Status:Needs review» Reviewed & tested by the community

Putting back to RTBC

Status:Reviewed & tested by the community» Closed (duplicate)