Hi,
I'd upgraded my Moodle from v3.11 to v4.0 successfully, then to v4.1 latest version and it passed with no problems.
But when upgrading to v4.2.11 as shown:
== Upgrading Moodle database from version 4.1.15+ (Build: 20241213) (2023041100) to 4.2.11 (Build: 20241007) (2023042411) ==
And the updater is stuck for more than 2 hours at:
-->assignfeedback_editpdf
I read that there was a bug related to this issue, but it supposed to be fixed!
Should I wait for it to finish, or what?
Best regards,
SELECT * FROM mdl_task_adhoc WHERE classname = '\\assignfeedback_editpdf\\task\\convert_submission' AND component = 'assignfeedback_editpdf' AND customdata = '{\"submissionid\":\"1017789\",\"submissionattempt\":\"0\"}'Got command line? If the browser times out or hangs, one can pickup where left off (even run forever until completed in background with nohup wrapper) using code/admin/cli/ and the upgrade.php script from command line.
'SoS', Ken
I'm using the command line.
After about 24 hours, I logged-in but it seems that the database upgrade didn't finish yet! And the /mod/assign/feedback/editpdf still needs to be upgraded.
What should I do now to prevent that issue from happening again?
Don't really know what is going on with your server, but did notice in the tracker repeated running of admin/cli/adhoc_task.php script.
That version had an annoying issue with the running of cron job looping adhoc task for 180 times. Cron job would run again in the middle of the looping. I had to change behavior by adding a line to config.php:
$CFG->cron_keepalive='0';
to stop the behavior.
Since you have command line, run admin/cli/cron.php to see if your server is doing that.
'SoS', Ken
2 more suggestions on follow up ...
run admin/cli/check_database_schema.php
This has to do with Assignment convert submission etc.
Do you have Poppler installed?
Check System Paths
Path to pdftoppm comment:
"Poppler is a PDF rendering library which includes the tool pdftoppm for converting PDF files to PNG. Performance is generally better than when using Ghostscript, particularly for large files. If available, pdftoppm will be used in preference to Ghostscript."
'SoS', Ken
Running the check_database_schema.php returning the following:
[12/19/24 09:00] root@lms:/var/www/moodle# php admin/cli/check_database_schema.php-------------------------------------------------------------------------------ltiservice_gradebookservices * column 'subreviewurl' is missing * column 'subreviewparams' is missing-------------------------------------------------------------------------------tiny_autosave * table is missing-------------------------------------------------------------------------------logstore_standard_log * Missing index 'userid' (not unique (userid)).CREATE INDEX mdl_logsstanlog_use_ix ON mdl_logstore_standard_log (userid); * Missing index 'courseid' (not unique (courseid)).CREATE INDEX mdl_logsstanlog_cou_ix ON mdl_logstore_standard_log (courseid); * Missing index 'realuserid' (not unique (realuserid)).CREATE INDEX mdl_logsstanlog_rea_ix ON mdl_logstore_standard_log (realuserid); * Missing index 'relateduserid' (not unique (relateduserid)).CREATE INDEX mdl_logsstanlog_rel_ix ON mdl_logstore_standard_log (relateduserid);-------------------------------------------------------------------------------assignfeedback_editpdf_queue * table is not expected-------------------------------------------------------------------------------
Why the assignfeedback_queue table is not expected!? Is it safe to drop it manually?
The others indicate issues with DB for sure.
To the question of drop that table manually, do an explain on that table to see what the columns are ... gives you an idea of what is going on. Moodle does build temp tables for ... as it says ... temporarily doing whatever. Temp tables are not normally seen.
Any que, however, sounds like something to be done ... by adhoc_task or next cron job run.
'SoS', Ken
There is Administration > Plugins > Activity modules > Assignment > Feedback plugins > Annotate PDF.
There was an old bug that Moodle did not respect this setting. I has been fixed in the late 3.x versions (from memory).
As you can notice in adhoc_task page:
There is the conversion task and when trying to Run all, the following happened:
Even if I disabled the Annotate PDF plugin they still exist, how can I discard them?
In your ad-hoc task there is a course_delete_modules task - failing. Wonder if that is deleting an assignment and that is what is affecting the conversion.
In moodle admin look for recyclebin. Set duration for 1 second and have the recyclebin show all the time in the course menus.
That hurries along the module deletions to trashdir where one can remove them manually.
Not sure your upgrade actually finished so from cli:
cd /path/to/moodlecode/admin/cli/
php upgrade.php
The very last process that does is check and set default settings for everything.
If it did indeed finish, the script will tell you not needed.
Also, in admin/cli/ there is a scheduled_task.php script.
Run without parameters will bring up help for the command.
php scheduled_task.php --list |grep cleanup
will list all the task for cleanups.
\core\task\file_trash_cleanup_task
\tool_recyclebin\task\cleanup_course_bin
\core_files\task\conversion_cleanup_task
I think you can run those individually while cron job is disabled.
Obviously you need to get control of this.
Am out of ideas ... cept one ...
Hope you began upgrades with a site backup! You might have to restore the site from the backup you took of the 4.1 ... importing the sql dump into a new database, change config.php DB array to match new DB.
Once restored and running ... then look into everything ... DB schema, Document conversions, etc. Do the recyclebin setting lower and showing in course menus. Get everything clean and working again. Make another site backup. Then do your upgrades again - this time from command line only.
One should not need to hack any core code.
'SoS', Ken
No, the course_delete_modules task is for a resource not an assignment.
The cleanup task looks doing its job:
Though to solve the stacked tasks in the task_adhoc table:
It might take days to finish, but the results look promising! specially that the database server is not hanging, and the web is working well.
P.S. I know I shouldn't hack the core code, and I didn't. I just changed the assignfeedback_editpdf version in the database just to let the updater skip the conversion temporarly.
Since my site in maintenance mode, neither the cron.php nor the adhoc_task.php is running, see this:
[12/19/24 09:00] root@lms:/var/www/moodle# php admin/cli/cron.phpCLI maintenance mode active, cron execution suspended.[12/19/24 09:03] root@lms:/var/www/moodle# php admin/cli/adhoc_task.phpCLI maintenance mode active, cron execution suspended.[12/19/24 09:05] root@lms:/var/www/moodle#
Ok, then ...
php admin/cli/maintenance.php --disable
php admin/cli/cron.php [enter]
when it finishes ... we hope ... BTW, one can cancel it with [CNTRL][C]
php admin/cli/maintenance.php --disable
'SoS', Ken
Finally, the update finished after I skipped the code that was causing the problem by changing the plugin version from 2022041902 to 2022061000.
The code is at line 61 in the file: /mod/assign/feedback/editpdf/db/upgrade.php
Congrats! However, that's core code. Never a good idea to modifiy core code - tends to bite ya on next upgrade (4.3, 4.4, 4.5 and beyond awaits you.
Me thinks a good idea to run the check schema again and address whatever it finds.
And one last suggestion:
Install MySQL Tuner
MySQL Tuner
https://github.com/major/MySQLTuner-perl
"MySQLTuner is a script written in Perl that will assist you with your MySQL configuration and make recommendations for increased performance and stability."
The key to a Moodle is a well tuned DB.
'SoS', Ken
-------------------------------------------------------------------------------assignfeedback_editpdf_queue * table is not expected-------------------------------------------------------------------------------in a m42 - 4.2.11 (Build: 20241007)
There is no table by that name ...
mysql> show tables like '%assignfeedback%';
+------------------------------------+
| Tables_in_m42sb (%assignfeedback%) |
+------------------------------------+
| mdl_assignfeedback_comments |
| mdl_assignfeedback_editpdf_annot |
| mdl_assignfeedback_editpdf_cmnt |
| mdl_assignfeedback_editpdf_quick |
| mdl_assignfeedback_editpdf_rot |
| mdl_assignfeedback_file |
+------------------------------------+
6 rows in set (0.01 sec)
Looks like it's a tracker for assign feedback.
Thus, safe to drop the table.
Did you add:
a line to config.php
$CFG->cron_keepalive='0';
Cron will not run in maintenance mode so you have to take site out of maintenance mode to check cron running.
From CLI and in code directory:
php admin/cli/maintenance.php --disable
php admin/cli/cron.php
You can cancel it with [ctrl][c]
can put site back in maintenance mode issuing:
php admin/cli/maintenance.php --enable
You can kill a process via
kill -9 PIDNUMBER
The hack you made of core code. What was it? Changed version number of a plugin to make it compat?
What was plugin name?
From CLI in code/admin/cli/
php uninstall_plugins.php --show-all
In the list of plugins, core assignment related should show:
assignsubmission_comments Submission comments
assignsubmission_file File submissions
assignsubmission_onlinetext Online text submissions
assignfeedback_comments Feedback comments
assignfeedback_editpdf Annotate PDF
assignfeedback_file File feedback
assignfeedback_offline Offline grading worksheet
'SoS', Ken
Please see below:
In v4.1 here: moodle/mod/assign/feedback/editpdf/db/upgrade.php at MOODLE_401_STABLE · moodle/moodle · GitHub
At line 61, there is a code block that checks plugin version and according to that it creates the: assignfeedback_editpdf_queue temp table and loops through its records and convert the submissions. This code had changed now and not exists in later versions.
What I did is changing the plugin version in the database to skip this code, but it looks like that the assignfeedback_editpdf_queue temp table has been already created, and its content has been scheduled as task_adhocs!
Why I can find that table mdl_assignfeedback_editpdf_queue inhere: moodle_405 Database
Anyway, I'll count on the:
php check_database_schema.php-------------------------------------------------------------------------------assignfeedback_editpdf_queue * table is not expected-------------------------------------------------------------------------------
Back it up first and then truncate it to see what will happened!