Error log full of errors relating to wp-cron.php

It could be a bot trying to hack your site.

@joyously can you elaborate on what leads you to suspect that it may be a bot trying to hack the site?

I have tried disabling plugins to see if it is related to a particular plugin. With all plugins disabled I do not get the errors (or at least not within a few minutes of observation).
Re-enabling the plugins one by one I found that there are multiple plugins that, when enabled, result in the errors to start accumulating again. Thes include widely used plugins such as BackWPup, Wordfence Security, WP Mail SMTP, Yoast SEO.
My only conclusion from this is that these plugins are triggering wp-cron.php and each time wp-cron.php is triggered I get an error logged.

Well, it was just a thought since there aren’t that many things using wp-cron.php directly like that. Or maybe your site does have something that invokes it directly?
Since the wp-cron.php file does have ignore_user_abort( true ); on line 19, it seems that your setup has something different that disables it. Do you have an ini file? Do you have a security plugin that affects it?

@joyously Only security plugin is Wordfence Security and it still occurs when that is disabled.

And yes, there is a php.ini file. I searched it for ignore_user_abort and found a reference to it:

; If enabled, the request will be allowed to complete even if the user aborts
; the request. Consider enabling it if executing long requests, which may end up
; being interrupted by the user or a browser timing out. PHP’s default behavior
; is to disable this feature.
; https://php.net/ignore-user-abort
;ignore_user_abort = On

As you can see it is commented out and from the notes in the comments, this would appear to be the default behaviour.

I contacted my hosting support and they informed me that ignore_user_abort is added to disabled functions for security reasons. Just wondering if anyone knows if it is common practice to disable ignore_user_abort and, if so, why is WordPress calling it without checking if it is available?

And also I’m wondering if it really is a security risk and whether I should remove it from the disable_functions list?

It is not common practice to disable the ignore_user_abort function, nor does it have any security implications.

The ignore_user_abort function is meant for command line PHP cases. Normally, when a script is run and then the terminal disconnects while it is running, the script will continue until it tries to produce output, at which point it would be terminated. Using the ignore_user_abort function allows that to be disabled, so that the script can continue running in the background.

The only potential security implication is having a script able to be run leading to a denial-of-service attack, however, this is not a real security issue. A script that produces no output will run regardless, so disabling ignore_user_abort doesn’t affect any meaningful real-world cases.

There is no valid reason for a host to disable the ignore_user_abort function.

That said, the use of it in wp-cron.php is only meant for cases where the wp-cron system is rigged up to a command line. This is not the default or normal case, and if you’re seeing the message from it being run by http, then the ignore_user_abort function does absolutely nothing. So it makes no difference whether the line is there or not. You can re-enable ignore_user_abort, or just remove that line from wp-cron.php. It’s not a good idea to edit core files, but in this case, that line makes zero difference to the functionality of the file.

@otto42 Thank you for that explanation, makes sense. My resolution was to remove ignore_user_abort from the disable_functions list, so I’m glad to hear there is no security issue with doing that. I would imagine that there is a server overhead with logging an error every few seconds and also it fills up the logs with garbage making it more difficult to if I need to refer to them to troubleshoot other issues.