Thanks to @Xon for identifying the bug fix where AJAX JSON responses would still trigger job.php; and for making suggestions on avoiding unnecessary database queries and prevent running cron jobs unless triggered via our CLI job runner
- changes: disable calculations for job auto run time to avoid unnecessary database queries
- bug fix: disable AJAX auto job runner from triggering from AJAX JSON responses
- changes: don't allow cron tasks to execute unless...
@Sim there are a couple places you need to override to stop job.php from being polled.
You want to extendPHP:class Manager extends XFCP_Manager { public $allowCron = false; public function setAllowCron($value) { $this->allowCron = $value; } public function scheduleRunTimeUpdate() { if (empty(\XF::options()->svRunCronFromCron)) { parent::scheduleRunTimeUpdate(); } } public function getRunnable($manual) { if ($manual || $this->allowCron) { return parent::getRunnable($manual); } if (empty(\XF::options()->svRunCronFromCron)) { return parent::getRunnable($manual); } return $this->db->fetchAll(" SELECT * FROM xf_job WHERE trigger_date <= ? AND manual_execute = ? AND unique_key != 'cron' ORDER BY trigger_date LIMIT 1000 ", [\XF::$time, $manual ? 1 : 0]); } }
\XF\Job\Manager::scheduleRunTimeUpdate
to catchautoJobRun
being updated to reduce unneeded DB writes.
Extending\XF\Job\Manager::getRunnable
is needed because if a job was queued in a request, then XF sets various attributes inaddDefaultJsonParams
based on internal state (and not the templateautoRun
variable!) which means thecron
job could be evaluated whenjob.php
executes.
Then update the CLI runner command to callsetAllowCron(true)
.
As for why you would want to block thecron
job from being executed viajob.php
;
View attachment 212841
Before 12:00, standard xf web-based cron withautoRun
being removed like your add-on does.
After 12:00, the above code changes in a private add-on is deployed.
This is the classic "thundering herd" problem, where a large number of requests wake up at once, all go to get a lock and then go back to sleep after most fail to get anything done.
job.php
to be called. Pretty simple fix to disable that - although calling job.php is still required for AutoBlocking jobs - since they change the UI and actually do need to be executed immediately (currently only used by the Approval Queue).New features:
- implemented debug logger for Job execution time tracking
- extend the XF\Job\Cron class with new run function which logs execution time for cron tasks
- added new Cli command and test job for testing purposes
I'm curious. Is there anyway I can see the debug output/input of the cronjob? Sometimes a specific cron job takes a long while finish, so it would be nice to know to see some kind of debug log as to see where it is "hanging". Without the quiet command line, it'll merely show "No more runnable jobs pending", but I assume that's what the quiet line hides.
xf:run-jobs
is run in Verbose (-v
), Very Verbose (-vv
) or Debug (-vvv
) modes./etc/systemd/system/xf-cron.timer
[Unit]
Description=Timer trigger for xf-cron service
Wants=network-online.target
[Timer]
OnBootSec=1min
OnUnitActiveSec=20sec
[Install]
WantedBy=multi-user.target
/etc/systemd/system/xf-cron.service
[Unit]
Description=xf-cron service
[Service]
Type=oneshot
User=www-data
Group=www-data
ExecStart=/usr/bin/php -q /path/to/your/forum/root/cmd.php --quiet xf:run-jobs
www-data
to the user your site runs as, and /path/to/your/forum/root/
as requiredsystemd daemon-reload
systemd enable xf-cron.timer
systemd start xf-cron.timer
-q and --quiet seems duplicate?-q /path/to/your/forum/root/cmd.php --quiet
-q and --quiet seems duplicate?
-q
is for PHP and --quiet
is the Symfony Cli used by XenForo.Push Notifications will be process via this addon/cron?
We use essential cookies to make this site work, and optional cookies to enhance your experience.