Hi All,
The enrol by user profile fields schedule task is not running any more. It says "Unable to get task lock for enrol_attributes\task\processenrolments_task". However, if you go to any of the courses and force enrollment, it works fine. Anyone have a clue how to resolve this? I've tried restarting MySQL services as well as a server restart. Thanks in advance.
Can you tell us what version of Moodle this is? From the Unable to get task lock presumably it's between Moodle 3.3 and 3.8.
Assuming Moodle 3.8, as far as I can see with MySQL it uses the filesystem for locking by attempting to obtain a lock on a file in the moodledata/lock subfolder. It looks like each lock file is specific to the scheduled task so it might be specifically moodledata/lock/5c/5c06584b18d6ad7a3d656bd935efc66b. Does this file exist? Can whichever user account the scheduled task being run as access write to this file? The timestamp of the file indicates when it was accessed and it contains the time it was written to in Unix epoch format.
Alternatively, you should be able to delete the file and if the Moodledata permissions are correct it will get re-created.
If it's still not working let us know the Moodle version, web server operating system, how the scheduled task is being run (for example: crontab), and also whether Moodledata is on a local filesystem or if it's some remote share such as NFS.
I even tried installing a cron lock plugin to give me more information. See screenshot
The obvious cause of Unable to get task lock would be that the initial run of the processenrolments_task isn't completing successfully, perhaps it's stuck in an infinite loop. Then any subsequent run of this task cannot get a lock and would show this error until the lock times out after 24 hours. Then the task would attempt to run again and, if the problem still exists, that lock will be held again and subsequent running of this task will fail with this error.
So you would need to troubleshoot this. Do you have command line access to the web server? If so try 1) enabling debugging (Debug messages: DEVELOPER, Display debug messages: Yes), 2) deleting the lock file, and 3) running the task at the command line. On my system the command is:
sudo -u apache php admin/tool/task/cli/schedule_task.php --execute='\enrol_attributes\task\processenrolments_task'.
You may need a user other than apache. Common ones are www-data or php-fpm.
It wont run with the cron auto scheduler – do you mean that the cron is running OK apart from this one task? Or is there a problem running the cron too. Are all the other scheduled tasks running OK?
Which version of the enrol by user profile fields plugin is this? Hopefully the latest, 2021100800.
There are two other issues:
Sorry if I wasn't clear on what I was suggesting.
For the user to run admin/tool/task/cli/schedule_task.php as, you will need to determine this. Checking which user owns the files in moodledata/filedir may help (for example: with ls -lh), or indeed the owner of moodledata/lock/5c/5c06584b18d6ad7a3d656bd935efc66b. Trying each user I gave as examples is unlikely to identify this user, and your server may have specific users for each web site.
You would then need to suspend the running of the site cron (admin/cli/cron.php). For example: make a note of the current entry, then remove it. If you don't suspend this then the cron will attempt to run processenrolments_task when the lock is deleted creating the lock file again and preventing the task being manually run.
Then enable debugging (Debug messages: DEVELOPER, Display debug messages: Yes).
Then delete the lock file, moodledata/lock/5c/5c06584b18d6ad7a3d656bd935efc66b.
Then run the task, sudo -u USERNAME php admin/tool/task/cli/schedule_task.php --execute='\enrol_attributes\task\processenrolments_task' where USERNAME is the server user account you have determined PHP scripts are being run as.
Hopefully there'll be some output, maybe an error message or other output providing some clue as to what is going wrong with the task. The problem with the lock file suggests the task doesn't end normally but it may just hang,
Then turn debugging off again, you don't normally want this on a production site.
Then unsuspend the site cron, for example: add this again if it was removed.
You need to use cd to change into the Moodle source code folder first. You'll need to work out the name of this folder – it contains the Moodle source code for your site – it's probably called something like public_html or moodle. For example, if it's the former the commands would be:
cd public_html
sudo -u "USERNAME" php admin/tool/task/cli/schedule_task.php --execute='\enrol_attributes\task\processenrolments_task'
The output:
Status: 404 Not Found
Content-type: text/html; charset=UTF-8
suggests that the build of PHP on your server is always expecting to send output to the browser, not to the command line. I've seen this before but I don't know why it happens. But hopefully it won't affect running the above command.
Remember, you will need to have debugging enabled for this test – and delete the lock file – to run the processenrolments_task and see if it reports errors. However, if you're running Moodle 3.5 on PHP 7.4 then expect to lots of other errors (such as PHP Deprecated warnings) because Moodle 3.5 doesn't support PHP 7.4.
