Cron: Make response flushing optional#12222
Conversation
A client's site has been having difficulties running wp-cron jobs. Within 1 second, the wp-cron process get killed. This usually happens in unsuspecting places such as the middle of an SQL request or REST API call, but almost always within the first 1-2 seconds.
However, the exact same functions can be run as a foreground process in PHP without issue.
This has caused issues with Action Scheduler, WooCommerce lookup tables have become out of sync and my own ERP sync solution for WordPress stopped sync.
Running the site locally in PHP-FPM does not reproduce the issue.
I have traced the issue to wp-cron calling `litespeed_finish_request()` when that function is available. However in this case, the LSPHP web server seems to kill the resulting child process within a second from spawning it.
This also seems to cause some memory leaks and swapping in the LSPHP web server.
The issue has been mended on the client's site by commenting out the following code block in wp-cron.php:i
```php
if ( function_exists( 'fastcgi_finish_request' ) ) {
fastcgi_finish_request();
} elseif ( function_exists( 'litespeed_finish_request' ) ) {
litespeed_finish_request();
}
```
In order to prevent this and similar issues, I suggest adding a new config constant; `WP_CRON_FLUSH`, defaulting to true to optionally enable flushing wp-cron response data and continuing in the background.
I also suggest `WP_CRON_IGNORE_ABORT`, defaulting to true to indicate whether or not to call `ignore_user_abort( true )` as it may cause similar issues.
It has taken me a while to trace the issue to wp-cron and LSPHP as this had all the symptoms of a memory constrained web server.
I have communicated this issue with the relevant hosting provider as I am uncertain if this is isolated to their hosting packages or if this is more widespread. However, I have concluded that is warrants a patch to the WP Core to make flushing response data and spawning a child process using `fastcgi_finish_reques()` or `litespeed_finish_request()` optional.
An added benefit to this is this makes it easier and more straightforward to debug wp-cron jobs, as `WP_DEBUG_DISPLAY` can be set to true along with `WP_CRON_FLUSH` to false. In addition, tasks that should take more than a couple of seconds but crash can be identified using browser tools or cron without running something like New Relic to identify issues.
I don't expect this to require unit tests as this concerns specific
application servers.
The issue has been mended by commenting out the following code block in wp-cron.php:
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the Core Committers: Use this line as a base for the props when committing in SVN: To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Hi there! 👋 Thank you for your contribution to WordPress! 💖 It looks like this is your first pull request to No one monitors this repository for new pull requests. Pull requests must be attached to a Trac ticket to be considered for inclusion in WordPress Core. To attach a pull request to a Trac ticket, please include the ticket's full URL in your pull request description. Pull requests are never merged on GitHub. The WordPress codebase continues to be managed through the SVN repository that this GitHub repository mirrors. Please feel free to open pull requests to work on any contribution you are making. More information about how GitHub pull requests can be used to contribute to WordPress can be found in the Core Handbook. Please include automated tests. Including tests in your pull request is one way to help your patch be considered faster. To learn about WordPress' test suites, visit the Automated Testing page in the handbook. If you have not had a chance, please review the Contribute with Code page in the WordPress Core Handbook. The Developer Hub also documents the various coding standards that are followed:
Thank you, |
aldavigdis
force-pushed
the
make-response-flush-optional-in-cron
branch
from
cf21898 to
764ad5d
Compare
Test using WordPress PlaygroundThe changes in this pull request can previewed and tested using a WordPress Playground instance. WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser. Some things to be aware of
For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation. |
1 participant
A client's site has been having difficulties running wp-cron jobs. Within 1 second, the wp-cron process get killed. This usually happens in unsuspecting places such as the middle of an SQL request or REST API call, but almost always within the first 1-2 seconds.
However, the exact same functions can be run as a foreground process in PHP without issue.
This has caused issues with Action Scheduler, WooCommerce lookup tables have become out of sync and my own ERP sync solution for WordPress stopped sync.
Running the site locally in PHP-FPM does not reproduce the issue.
I have traced the issue to wp-cron calling
litespeed_finish_request()when that function is available. However in this case, the LSPHP web server seems to kill the resulting child process within a second from spawning it.This also seems to cause some memory leaks and swapping in the LSPHP web server.
The issue has been mended on the client's site by commenting out the following code block in wp-cron.php:
In order to prevent this and similar issues, I suggest adding a new config constant;
WP_CRON_FLUSH, defaulting to true to optionally enable flushing wp-cron response data and continuing in the background.I also suggest
WP_CRON_IGNORE_ABORT, defaulting to true to indicate whether or not to callignore_user_abort( true )as it may cause similar issues.It has taken me a while to trace the issue to wp-cron and LSPHP as this had all the symptoms of a memory constrained web server.
I have communicated this issue with the relevant hosting provider as I am uncertain if this is isolated to their hosting packages or if this is more widespread. However, I have concluded that is warrants a patch to the WP Core to make flushing response data and spawning a child process using
fastcgi_finish_reques()orlitespeed_finish_request()optional.An added benefit to this is this makes it easier and more straightforward to debug wp-cron jobs, as
WP_DEBUG_DISPLAYcan be set to true along withWP_CRON_FLUSHto false. In addition, tasks that should take more than a couple of seconds but crash can be identified using browser tools or cron without running something like New Relic to identify issues.I don't expect this to require unit tests as this concerns specific application servers.
Trac ticket: https://core.trac.wordpress.org/ticket/65474
Use of AI Tools
No AI tools used.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.