Re: Moodle in docker environent
upgrade from 4.41 to 4.42 fails to restart
This is the error I get when I go to the site URL.
Warning: Class "core\context\block" not found in site/lms/lib/accesslib.php on line 5049
Warning: Class "core\context\course" not found in site/lms/lib/accesslib.php on line 5050
Warning: Class "core\context\coursecat" not found in site/lms/lib/accesslib.php on line 5051
Warning: Class "core\context\module" not found in site/lms/lib/accesslib.php on line 5052
Warning: Class "core\context\system" not found in site/lms/lib/accesslib.php on line 5053
Warning: Class "core\context\user" not found in site/lms/lib/accesslib.php on line 5054
Exception - Class "core\lock\file_lock_factory" not found
Re: upgrade from 4.41 to 4.42 fails to restart
Re: upgrade from 4.41 to 4.42 fails to restart
+1 to what Howard asked ... in addition ...
Got command line access to your server? If so, change into code/admin/cli/ and execute the following:
php scheduled_task.php --execute="\core\task\task_lock_cleanup_task"
above is all on one line ... word wraps in these forums.
'SoS', Ken
Re: upgrade from 4.41 to 4.42 fails to restart
Follow up question ... this part ... 'fails to restart' ... mind describing that? One doesn't 'restart' to upgrade a site - normally.
'SoS', Ken
Re: upgrade from 4.41 to 4.42 fails to restart
1. put site into maintenance mode
2. Unzipped the upgrade package locally
3. Added plugins into appropriate directories
4. Added config.php file
5. Moved existing server code
6. Replaced with new code using FileZilla
Running the command line entries you suggested yielded the following
php scheduled_task.php --execute="\core\task\task_lock_cleanup_task"
Warning: Class "core\context\block" not found in /site/lms/lib/accesslib.php on line 5049
Warning: Class "core\context\course" not found in /site/lms/lib/accesslib.php on line 5050
Warning: Class "core\context\coursecat" not found in /site/lms/lib/accesslib.php on line 5051
Warning: Class "core\context\module" not found in /site/lms/lib/accesslib.php on line 5052
Warning: Class "core\context\system" not found in /site/lms/lib/accesslib.php on line 5053
Warning: Class "core\context\user" not found in /site/lms/lib/accesslib.php on line 5054
WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
!!! Exception - Class "core\lock\file_lock_factory" not found !!!
php scheduled_task.php --execute="\core\task\task_lock_cleanup_task"
Warning: Class "core\context\block" not found in /site/lms/lib/accesslib.php on line 5049
Warning: Class "core\context\course" not found in /site/lms/lib/accesslib.php on line 5050
Warning: Class "core\context\coursecat" not found in /site/lms/lib/accesslib.php on line 5051
Warning: Class "core\context\module" not found in /site/lms/lib/accesslib.php on line 5052
Warning: Class "core\context\system" not found in /site/lms/lib/accesslib.php on line 5053
Warning: Class "core\context\user" not found in /site/lms/lib/accesslib.php on line 5054
WARNING: MYSQL_OPT_RECONNECT is deprecated and will be removed in a future version.
!!! Exception - Class "core\lock\file_lock_factory" not found !!!
Re: upgrade from 4.41 to 4.42 fails to restart
Re: upgrade from 4.41 to 4.42 fails to restart
I hope you began with a site backup ... code + DB dump + minimal moodledata/filedir/ - you might have to restore to 4.4.1.
The plugins you added back to new code ... what were they and do they have a compat version for destination version? a block?
The warnings start with block, then course, course category ...
Did find a very old tracker:
https://tracker.moodle.org/browse/MDL-77852
Think I'd try nothing but command line:
in admin/cli/
purge_caches.php
first, then
upgrade.php
Fingers crossed for ya!
'SoS', Ken
Re: upgrade from 4.41 to 4.42 fails to restart
Time for a change! You have command line and appears you are not suffering from 'clas' (command line avoidance syndrome)! Image may be NSFW.
Clik here to view.
First, restore your 4.4.1 and get that working again.
Then, 'gitify' that version. Using git to update/upgrade moodle code means no more moving parts ... copy back in anything, etc. ... code stays were it is and git literally pulls in new code, deletes code no longer needed, and updates files that need changing.
You will have to do that copy back into new code directory one time when 'gitifying' your code directory. But that will be the last time you do that!
Your first use of git on your 4.4.1 code will acquire the point release.
And, with a bash shell script you can create an 'up' script that backs up the site just prior to updating the site, checks environment, runs cron one last time before upgrading, puts site in maintenance mode, then literally pulls new code as described above, and runs the upgrade using script in code/admin/cli/.
Such a script can have pauses in it that would allow you to cancel it should something major rear it's ugly head.
Barring any issues (that probably were in existence prior to the update), the CLI method using git takes a matter of minutes.
Anyhoo ... my 2 cents!
'SoS', Ken
Serious database preformace problems after upgrade
Hello,
I have upgraded from Moodle 3.11.x to 4.1, 4.2 and then 4.3 via GIT and PHP from 7.4 to 8.0 and 8.1.
Upgrade was smooth, all conditions and parameters were satisfied. I have just solved some problems with plugins.
But I am sometimes getting this error and Moodle is horribly slow. I have really premium cloud hosting with Maria DB and I am only one user of the Moodle now during holiday. I did a lot of work on upgrade but I see, that I should revert at least on 4.1 or 3.11 branch. I don't know how to deal with this behavior.
Error
Error: Database connection failed
It is possible that the database is overloaded or otherwise not running properly.
The site administrator should also check that the database details have been correctly specified in config.php
Re: Serious database preformace problems after upgrade
And this happens sporadically? Can you relate it to some event, like heavy traffic or the times when a backup process runs in the background?
Either way, the information requested in Before you post.. read this.. are always useful.
Re: MariaDB 10.6 support on Redhat
Re: Serious database preformace problems after upgrade
Firstly, turn on Debugging and get the full trace when you get that error. What is the database doing when it fails ('show processlist' at the very least)?
Re: MariaDB 10.6 support on Redhat
Re: MariaDB 10.6 support on Redhat [SOLVED]
Re: upgrade from 4.41 to 4.42 fails to restart
Re: upgrade from 4.41 to 4.42 fails to restart
Re: Moodle in docker environent
VOW!
Thanks the two of you for your targeted help!
https://github.com/moodlehq/moodle-docker worked rightaway. I can switch versions very easily via the shell variables. That will help me for the upgrading process.
However with regard to the final production server the goal remains, to have an nginx as webserver in combination with php-fpm. So you think it is ok to run nginx with php-fpm in the same docker-container ? Is there nginx solution provided by Moodle ?
So I verified the nginx.conf (i.e. /etc/nginx/conf.d/default.conf in the php-fpm-container) with recommended conf of moodle on https://docs.moodle.org/404/en/Nginx.
Here is my nginx.conf:
Image may be NSFW.
Clik here to view.
It differs to my conf because I want to present the site on localhost:8080. So I need to take care of the server port 8080. The rest is more or less the same as by moodle recomended. The point is that I say
fastcgi_pass php:9000
instead of
fastcgi_pass 127.0.0.1:9000
because I wanted a different docker container to take care of the php-fpm-service.
When I open "http://localhost:8080/user/editadvanced.php?id=2" with that conf i get the following output in the network tab of my console.
Image may be NSFW.
Clik here to view.
Docker conf looks like:
1.) Dockerfile
Image may be NSFW.
Clik here to view.
2.) docker-compose.yml
Image may be NSFW.
Clik here to view.
If you have a hint or further information for me I would be greatful !
Best,
Steve
Re: Serious database preformace problems after upgrade
Yes, MariaDB is running on the same server ('localhost'). Below is the relevant part of the config.php file related to the database configuration:
php
$CFG->dbtype = 'mariadb';
$CFG->dblibrary = 'native';
$CFG->dbhost = 'localhost';
$CFG->dbname = 'u117824311_wl8lms';
$CFG->dbuser = 'u117824311_wl8lms';
$CFG->dbpass = 'your_db_password'; // hidden for security reasons
$CFG->prefix = 'mdl_';
$CFG->dboptions = array (
'dbpersist' => false,
'dbsocket' => false,
'dbport' => '',
'dbhandlesoptions' => false,
'dbcollation' => 'utf8mb4_czech_ci',
);
Regarding the sporadic outages, they are not tied to any specific event like heavy traffic or backup processes as far as I can tell. The load average is normal most of the time, but Moodle experiences random 503 errors. The error log is clean, and cron jobs are running without failures.
On August 14th, there was a 500 error due to the hosting server running out of disk space. Moodle was in maintenance mode at that time. Could this disk space issue have caused any corruption in the Moodle installation or database? After clearing space, I completed the upgrade without any errors, and all checks passed successfully.
I will check the suggested resources from the forum post you linked, but I would appreciate any additional guidance on what to look for or how to further diagnose this issue.
Server is Litespeed, PHP 8.1, MariaDB 10.6.
Thank you
Jiri
Re: Serious database preformace problems after upgrade
thank you for your response.
I understand that the database layer in Moodle hasn't changed much, so it's less likely that the version upgrade itself is the root cause. However, I have been encountering sporadic database connection issues and occasional 503 errors since the upgrade.
I already had Debugging turned on during the entire upgrade process, but I didn’t capture any errors specifically related to the database. I have now enabled detailed Debugging again and will monitor the full trace the next time the issue occurs.
As for the database, I've run SHOW PROCESSLIST when these issues arise, and the results don't indicate any obvious long-running queries or locked processes. The processlist typically shows processes in the Sleep state or quick-running queries, even during these outages.
Given the sporadic nature of the issue and the lack of any clear error messages or process locks, I’m wondering if there could be other underlying issues such as a misconfiguration or a hardware resource problem that might only manifest under specific conditions.
Do you have any suggestions on specific configurations to check or additional diagnostics to run in this case?
Thank you for your support.
Best regards,
Jiri