We should be proactive in ensuring that the environment is clean when
running a task. We already ensure that we have a clean renderer and
other parts of the output chain, but we were not setting a clean user.
This change adds a call to setup the cron user before each task is
actually executed.
* CLI adhoc_task.php: new option --taskslimit
* CLI adhoc_task.php: --execute option is implied when other options are given
* core\task\manager::get_next_adhoc_task(): new param $number
for limiting number of tasks to run
* CLI adhoc_task.php: new option --id
* cron::run_adhoc_task($taskid) for running tasks by id
* core\task\manager::get_adhoc_task($taskid) for retreival/locking
Adding LIMIT to the primary auth type SQL statement does not play well
with Oracle. We can just remove the LIMIT clause from the SQL statement
and and pass IGNORE_MULTIPLE to the call to $DB->get_field_sql()
instead.
When fetching the list of tasks to run, we were using the _process_
start time as a base. The various task fetchers (adhoc and scheduled)
only fetch tasks which were due to run _before_ this time.
With the new keepalive setting, we need to pass both the process start
time, and the run start time. We need to use the process start time to
determine whether MUC caches have been cleared since the process
started. but the run start time to fetch recent runs.
The Assignment 2.2 activity module was disabled in 2012 but kept to
enable pre-2.2 backups to be restored and have the assignments
auto-converted to new assignments. After almost 10 years, it's time
to remove it from Moodle core.
Add the DB type, count of courses with start or end dates set,
default site theme, and primary auth type statistics to those
collected as part of the site registration data.
If for any reason a Redis session lock is not being released, all subsequent
requests will wait to acquire the lock, forcing them to time out eventually.
This will happen till the original lock finally expires after the session timeout.
This sets the Redis session lock expiry time to whatever is lower,
either the PHP execution time `max_execution_time`, if the value was
defined in the `php.ini` or the globally configured `sessiontimeout`.
Setting it to the lower of the two will not make things worse it if the
execution timeout is longer than the session timeout.
For the PHP execution time, once the PHP execution time is over, we can
be sure that the lock is no longer actively held so that the lock can
expire safely. Although at `lib/classes/php_time_limit.php::raise(int)`,
Moodle can progressively increase the maximum PHP execution time, this
is limited to the `max_execution_time` value defined in the `php.ini`.
For the session timeout, we assume it is safe to consider the lock to
expire once the session itself expires.
If we unnecessarily hold the lock any longer, it blocks other session
requests.
Co-authored-by: Daniel Ziegenberg <daniel@ziegenberg.at>
Signed-off-by: Daniel Ziegenberg <daniel@ziegenberg.at>
