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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Damien Tournoud’s picture

Version: 7.0-alpha7 » 7.x-dev
Status: Active » Needs review
FileSize
1.18 KB

Good point.

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

mnicholas’s picture

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

perusio’s picture

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,

AntonioGM’s picture

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

MustangGB’s picture

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)

MustangGB’s picture

Status: Needs review » Reviewed & tested by the community

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

catch’s picture

Status: Reviewed & tested by the community » Needs work

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

perusio’s picture

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

MustangGB’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

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

MustangGB’s picture

Version: 7.x-dev » 8.x-dev
Status: Needs work » Needs review
Issue tags: +Needs backport to D7
FileSize
987 bytes

Rerolled

MustangGB’s picture

Status: Needs review » Reviewed & tested by the community

Putting back to RTBC

catch’s picture

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