wp-cron throws 500 errors for SSL enabled sites

[coatesg]

I have several WP installs that are throwing 500 error codes when calling wp-cron.php after a pageview. The error is not consistent - it will sometimes return 200, and sometimes 500. All the installs I see this on use SSL with properly signed certs with SNI in use on the server under Apache. Instances on the same server where do not use SSL have not shown this issue at all.

I have managed to reproduce this on a clean WP install running twentyfifteen with no plugins installed so it doesn't appear to be plugin related.

Oddly, I don't get any PHP warnings when it happens (though I've tested that if I force a php script in the same pool to throw an error, it does get captured) - I do get the following recorded in the Apache Virtualhost error log (redacted):

[Fri May 08 08:29:34.479946 2015] error [pid 13870:tid 140644332824320] [client xxxx:xxxx:x:xx:xxxx:xx:x:x:57492] AH00524: Handler for fastcgi-script returned invalid result code 32

Apache access log (redacted):

xxxx:xxxx:x:xx:xxxx:xx:x:x - - [08/May/2015:08:29:26 +0100] "POST /wp-cron.php?doing_wp_cron=1431070166.8151741027832031250000 HTTP/1.0" 500 4066 "-" "WordPress/4.2.2; ​https://www.domain.com"

System config is as follows:

• Fully patched Debian Jessie running on amd64 arch with kernel 3.16.0
• Webserver: Apache/2.4.10 (Debian), mod_fastcgi/mod_fastcgi-SNAP-0910052141, mod_fcgid/2.3.9, mod_python/3.3.1, Python/2.7.9, OpenSSL/1.0.1k
• MySQL 5.5.43-0+deb7u1
• PHP 5.6.7+dfsg-1 running under PHP-FPM (seen with and without opcache in place)
• Wordpress 4.2.2 fresh install (also seen on 4.2.1) with all plugins removed.

The server listens both on IPv4 and IPv6 - I've tried forcing wp-cron to use IPv4 by setting the hostname in /etc/hosts but that makes no difference.

Refer also to :

​https://wordpress.org/support/topic/wp-cron-throwing-500-errors-on-ssl-sites?replies=9

[Dukessa]

I have the same issue & webserver config, with WP 4.4.2 .
Did anyone manage to understand what's going on?

[coatesg]

No - I still have the same issue - would be nice if it was actually reviewed...

[dd32]

Unfortunately there's nothing in this ticket that can be used to determine if there's a WordPress bug, server configuration issue, or apache bug.

A 500 response is usually in response to a PHP Fatal Error, and without that error message there's not a lot we can do.

Looking at my own HTTPS site cron logs, there's a few errors from the cronjob taking longer than the server is willing to wait, in my case they return 499's as it's nginx, but Apache might record that as a 500 (499 is specific to nginx).

If you can provide more details into the actual issue, some log files which show why a 500 is thrown, or anything else at all really that shows a WordPress bug then please feel free to re-open this.

If you need help diagnosing if it's a bug, the ​support forums may help narrow it down.

[johnbillion]

Additionally, it would help to determine what "result code 32" infers. It could be related to a memory or timeout issue.

[razer0r]

I experience the same thing on a blog of one of my customers.

apache error log:

[Thu Aug 18 13:00:56.728037 2016] [core:error] [pid 12276] [client 81.4.126.89:57115] AH00524: Handler for fastcgi-script returned invalid result code 32

apache access log:

81.4.126.89 - - [18/Aug/2016:15:22:26 +0200] "POST /wp-cron.php?doing_wp_cron=1471526545.9875950813293457031250 HTTP/1.0" 500 3834 "-" "WordPress/4.5.3; https://gewoon-wij.be"

wp-config.php:
default; nothing fancy

Version: 5.4.3 (as shown in the apache access log)

[dd32]

Took a quick look around, and it does seem to be caused by WordPress, kind of.

The error 32 part seems to mean that the WordPress HTTP client has disconnected the SSL socket before the data comes back over the wire.
wp-cron specifically does this, it doesn't care about the response, so it disconnects from the stream ASAP, but Apache/FastCGI don't seem too happy with.

I don't think anything needs doing in WordPress here on the cron requesting side, but maybe we can respond to the cron HTTP request/socket with headers and a body quicker and avoid the logged warning.

Edit: Here's a non-WordPress example of how to cause this: ​https://ubuntuforums.org/showthread.php?t=2277794

[omriamos]

I have the same issue.
Is there a fix for this?

[timon33]

I have the same issue.
Version 4.7.3

[skutzke]

Same issue with version 4.8.2
Anything new?

[hardesfred]

Still occuring with version 4.8.3.

I'd be inclined to say that this is very specific to WordPress : we have many sites with different CMS hosted on our web servers, most of them perform cron tasks, and the error only appears for WordPress based sites.

[hardesfred]

It should be noted that the error does not prevent the cron process from running. We made some tests and despite the error, our cron job was in fact completed everytime.

Also, the error doesn't seem to related to WordPress (mea culpa). Apache or PHP-FPM would be the culprit (​https://ubuntuforums.org/showthread.php?t=2277794).

Still, increasing the timeout value in the "cron_request" filter (wp-includes/cron.php line 333) from 0.01 to a higher value prevents the error from occuring.