• Hi,

    I’m seeing some odd behaviour with wp-cron. I have a server that has just been upgraded to Apache 2.4/PHP 5.6.7 running under PHP-FPM (on Debian Jessie – was previously on Apache 2.2/PHP 5.4) – I’m seeing 500 errors for wp-cron.php, but not consistently, and these only occur for sites that use SSL (which all use SNI and properly signed valid certs). There are other non-SSL WP sites running on the same server in the same FPM pool that have no errors of this sort – and there’s nothing obvious in the logs detailing any errors (though I can manually trigger errors in a php file and these are logged as expected).

    Apache access log entries for wp-cron.php (redacted):

    [IP ADDRESS] – – [05/May/2015:11:39:10 +0100] “POST /wp-cron.php?doing_wp_cron=1430822350.4234778881072998046875 HTTP/1.0” 200 4162 “-” “WordPress/4.2.1; https://www.domain.com”
    [IP ADDRESS] – – [05/May/2015:11:39:38 +0100] “POST /wp-cron.php?doing_wp_cron=1430822378.2718520164489746093750 HTTP/1.0” 500 4094 “-” “WordPress/4.2.1; https://www.domain.com”

    I seem to get FPM errors of the following sort logged but nothing to indicate what could be the issue here (redacted):

    [Tue May 05 11:39:43.777552 2015] [core:error] [pid 19131:tid 139802049472256] [client [IP ADDRESS]:36077] AH00524: Handler for fastcgi-script returned invalid result code 32
    [Tue May 05 11:41:27.072108 2015] [core:error] [pid 19131:tid 139801923581696] [client [IP ADDRESS]:36089] AH00524: Handler for fastcgi-script returned invalid result code 32

    Any advice here as to how I can further go about diagnosing these issues? I have disabled opcache in PHP as well as WP Super Cache to no effect…

    Thanks

Viewing 12 replies - 1 through 12 (of 12 total)
  • Thread Starter coatesg

    (@coatesg)

    (Should have said – this is on WordPress 4.2.1).

    I’m having the exact same issue on a couple of my sites on Ubuntu 14.04.2/Apache 2.4.7/PHP-FPM 5.5.9/WordPress 4.2.2.

    It wasn’t happening before I changed the sites to use SSL/SNI so I think the issue is related to that.

    I’ll post if I find a solution.

    Thread Starter coatesg

    (@coatesg)

    Great – be good to resolve this. I’m trying a test site to see if I can reproduce it from fresh – I’m getting it on 4 separate WP instances so not sure it’s something specific (or at least it’s something they all share).

    I should have said that my server responds on both ipv4 and ipv6 – but I’ve forced each to do the wp-cron calls over v4 by setting the sites host names in /etc/hosts and that hasn’t fixed it…

    Almost certain it’s something ssl related and something I didn’t see happen in php5.4.

    Cheers

    I have also tried putting the sites into the hosts file with no success.

    I wonder if this is a php-curl/loopback issue combined with ssl. I think wp-cron might use that. One of my sites is using the alternate cron (define(‘ALTERNATE_WP_CRON’, true); in wp-config.php) and it does not have the issue.

    Are you using BackupBuddy? I think the error only occurs for me when scheduled backups occur. I’ve found that I can trigger the error on demand when I manually do a BackupBuddy backup..

    I traced the error back to a curl error: “Operation timed out after 1001 milliseconds with 0 bytes received”. Maybe there is something that changed with curl or the way wordpress uses it relating to timeouts.

    Thread Starter coatesg

    (@coatesg)

    Nope – I don’t use that plugin (I backup DB+code using OS based tools)

    I’ve had it happen once so far on a fresh install which was running some fairly common plugins (Akismet, WP Super Cache, Jetpack, Yoast SEO and a few others that I had on another site). I’ve chopped this back to core+Jetpack, Akismet & WP Super Cache to see if I can still trigger it (though obviously I don’t have many cron jobs to fire as a result…).

    Thread Starter coatesg

    (@coatesg)

    Confirmed – I can reproduce this with just that set of code. Next step probably to try and reproduce on core install only with no plugins…

    It’s something to do with the way wordpress/curl handles ssl. I’ve created a script that I can use for testing:

    <?php
    
    require( dirname( __FILE__ ) . '/wp-config.php' );
    
    $options = array (
      0 => 'http://site/test.php',
      1 =>
      array (
        'method' => 'POST',
        'timeout' => 0.01,
        'redirection' => 5,
        'httpversion' => '1.0',
        'user-agent' => 'WordPress/4.2.2; https://site',
        'reject_unsafe_urls' => false,
        'blocking' => false,
        'headers' =>
        array (
          'Accept-Encoding' => 'deflate;q=1.0, compress;q=0.5, gzip;q=0.5',
          'Content-Length' => 0,
        ),
        'cookies' =>
        array (
        ),
        'body' => NULL,
        'compress' => false,
        'decompress' => true,
        'sslverify' => false,
        'sslcertificates' => 'site-path/wp-includes/certificates/ca-bundle.crt',
        'stream' => false,
        'filename' => NULL,
        'limit_response_size' => NULL,
        '_redirection' => 5,
        'ssl' => true,
        'local' => true,
      ),
    );
    
    $curl = new WP_HTTP_Curl;
    
    var_dump($curl->request($options[0], $options[1]));

    The test.php script referenced above simply sleeps for 2 seconds to trigger the timeout.

    If I use the url: http://site/test.php then it times out but the webserver returns a code 200. If I use the url: https://site/test.php then it times out but the webserver returns a code 500. So something is different between how ssl and non-ssl are handled by WordPress’s WP_HTTP_Curl class.

    Thread Starter coatesg

    (@coatesg)

    Ah – good stuff. I’ve also reproduced this on a fresh 4.2.2 with no plugins. Have raised a defect as:

    https://core.trac.wordpress.org/ticket/32306#ticket

    Do you want to add your findings onto that bug?

    This is a tough one. At this point I don’t think it is a WordPress bug. I’ve narrowed the issue down to these two scripts:

    test.php:

    <?php
    
    $c = curl_init("https://[your-site-here]/delay.php");
    curl_setopt($c, CURLOPT_TIMEOUT, 1);
    curl_exec($c);

    delay.php:

    <?php
    
    sleep(2);

    If you use https to access delay.php in test.php, it throws the 500 error. If you use http, it gives a normal 200.

    I think it’s an issue in either php5-fpm, apache, or the fastcgi module. I tried using tcpdump to look at the communication between php5-fpm and apache but so far I haven’t been able to figure anything out.

    Thread Starter coatesg

    (@coatesg)

    I can’t reproduce this using your scripts – with https in test.php, it returns 200 after the timeout period. I can only trigger an issue in both http and https by extending delay.php beyond 30sec and getting rid of the cron opts in test.php (where it subsequently times out – I assume this is a script timeout – though oddly this looks like it should be 60sec from my fpm/php.ini…) – none of my requests that fail on wp-cron in normal use seem to last this long from looking at log timings…

    Strange. At this point I can reliably trigger the error using only the delay.php script. I simply use curl or wget to access delay.php and then interrupt it with Ctrl+C. When using ssl it throws the 500 error, when using plain http it returns 200. It only happens when I make the request on the server that is hosting delay.php. If I try the same thing from outside of the server both return the 200 response.

    I created a new thread on the Ubuntu forums hoping someone else has had this issue before but so far there are no responses.

    http://ubuntuforums.org/showthread.php?t=2277794

Viewing 12 replies - 1 through 12 (of 12 total)
  • The topic ‘wp-cron throwing 500 errors on SSL sites’ is closed to new replies.