Ajax cron problems

[PVince81]

Ajax cron doesn't run enough.
There are too many background jobs.

Adding some suggestions from other tickets:

shouldn't the administrator be warned in the webinterface that using AJAX-cron might not be enough (obviously a better strategy would be to fix the underlying issue)
shouldn't the webinterface tell the admin in any case that there is a backlog?
shouldn't there be an option to manually run the entire backlog (or parts thereof; running 120000 jobs might take a while and could effectively take the server offline)

from #27567 (comment)

[PVince81]

Also see locking issues where locks cannot be cleant up properly because ajax cron doesn't run often enough: #20380

Ideal would be to remove it completely but then users who deployed their ownClouds on shared hosting environments would not be able to setup system cron. Need an alternative solution...

[individual-it]

shouldn't the webinterface tell the admin in any case that there is a backlog?

or maybe even better to send an email

shouldn't there be an option to manually run the entire backlog (or parts thereof; running 120000 jobs might take a while and could effectively take the server offline)

is calling https://example.cloud/cron.php not effectively doing that?
If it takes to long PHP should run on max_execution_time. As sharehosters have often set that value restrictive it should not take the server down.

Other ideas:

• call cron.php with a max. number of jobs to be done. Then the page that runs the entire backlog calls cron.php again and again till the backlog if empty with a break in between the runs. Ideally cron.php would tell back if jobs are left or even how many.
• let the desktop client call the cron job periodically. That will not solve the problem totally because some users might use other WebDAV clients
• run cron jobs from remote.php if it was not run for a long time. That would have performance implications
• as Ajax Cron is the worse option, the default should be system or web-cron, maybe with a warning during installation (similar to the warning about installing on SQLite DB)

[PVince81]

As far as I remember ajax cron already has a max number of jobs to run, it doesn't run the whole backlog. Might still run into timeouts though.

[elzix]

Admin has 3 cron options. AJAX, WebCron, and Server Cron. Would Selecting a different cron solve the file locked issues (along with the backlog issues)?

[ghost]

@elzix

Also see locking issues where locks cannot be cleant up properly because ajax cron doesn't run often enough: #20380

-> #27574 (comment)

[lhartmann]

About stray locked files bug (#20380, which was closed in favor of this one)... If stray locks are old, and cron is overloaded and failing to clear them, then a possible solution is:

• Add a timestamp field to locks.
• When searching/locking Ignore locks older than, say, 24h.
• When deleting/unlocking remove ALL locks for the file.

Maybe this would lead the server to eventually fix itself, should a few locks go astray...

[PVince81]

@lhartmann this is actually a good idea. So the SQL queries inside DBLockingProvider need to be extended to contain a condition about the ttl.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[ownclouders]

Hey, this issue has been closed because the label status/STALE is set and there were no updates for 7 days. Feel free to reopen this issue if you deem it appropriate.

(This is an automated comment from GitMate.io.)

[PVince81]

In general stray locks is not the only problem. Anything that requires some task to run in the background will be affected and that could affect any app that uses this mechanism.

[stale]

This issue has been automatically closed.