Lazycron Stops Working

[netcarver]

In certain conditions on our production server, core's LazyCron module stops working totally and needs to be manually restarted by deletion of the site/assets/cache/LazyCronLock.cache file. This has been reported as far back as 2015 and is an ongoing issue that makes LazyCron too unreliable for serious use.

Expected behavior

LazyCron should be reliable enough to use in production, even if the code it's calling via hooks is not reliable.

Actual behavior

By failing to remove its lockfile when PHP Errors are raised, Lazycron stalls when it sees its lockfile still present and fails to be reliable for running any of its other hooks.

Cause of Issue

Investigation shows that whilst LazyCron is catching \Exceptions thrown from it's hooked calls, it is not handling PHP Errors. If any PHP error occurs in a called hook, Lazycron does not handle it and it bubbles up to the global error handler.

In these cases, LazyCron's lockfile is left on disk and the next call that invoke's Lazycron sees the lockfile and does not execute as it thinks another copy of itself might be running.

Suggestion for a possible fix

Now that PHP7 is common, both exceptions and errors are thrown and are catchable. Perhaps it's time to catch(\Throwable $e) as well as just catching exceptions. Specifically around L187 and L202. Something like the comment here.

Local testing shows that this does allow LazyCron to remove its lockfile when hooks generate errors. This allows subsequent executions of LazyCron to continue, and it should also allows later hooks in its list of hook methods to also be called, rather than being bypassed.

If PHP5 support is needed then a custom error handler should be included in LazyCron that cleans up the lockfile if an Error is raised.

Steps to reproduce the issue

Write a LazyCron hook that does a divide by zero or raises any other PHP error.

Setup/Environment

• ProcessWire version: 3.0.148
• PHP version: 5 or 7 - suggested fix only tried on PHP7.3

[ryancramerdesign]

Thanks @netcarver I've pushed a fix for this. At least, it seems to fix it in my testing here, but let me know if you continue to see the issue.

[netcarver]

@ryancramerdesign Thanks Ryan. Looks like this is a step in the right direction as it will handle one of the two problems reported initially - that of cleanup of the lock file. However, from code inspection alone, I don't think it will address the second issue - which I wasn't particularly clear about in the initial post. I do need to verify this is the case, but I suspect this still happens...

Let's say you have hooked three LC events; one on EveryMinute another one on Every5Minutes and the last one on Every10Minutes. No let's suppose the Every5Minute hook code always errors for some reason, but the other hooks run fine and they are both critical for the business.

Now, it appears to me that the hooks are called in order, from most frequent to least frequent (correct me if I'm wrong). So now this happens...

• EveryMinute is called and runs fine.
• Now Every5Minutes is called and errors. LC exits and the lockfile is removed, enabling it to run again the next minute. This is a big improvement on the previous version as at least the first hook is repeatedly run. But...
• Every10Minutes is never run.

With my proposed fix (catching \Throwables) this will be caught in PHP7+ installations and then the critical Every10Minutes hook would be called as well - so only the single, error-generating hook would fail to run.

I do need to verify by testing though.