FacebookTechnikai fórum
Moodle 4.0+ frissítés után hiba
Üdvözlet!
Olyan problémába futottam bele sajnos, hogy a moodle frissítése után (https://download.moodle.org/releases/latest/) az alábbi hibaüzenetet dobja a moodle belépés után: "HIBA!!! A használt kód RÉGEBBI, mint az ezen adatbázisok létrehozásához használt verzió." Erre a linkre lehet csak kattintani: https://docs.moodle.org/400/en/error/moodle/downgradedcore Viszont ez nem sokat segített sajnos. Mind a version.php-ben mind pedig a mdl_config táblában a verziók egyformák. A frissítést git pull-al végeztem, mint mindig.
sudo git pull
hint: Pulling without specifying how to reconcile divergent branches is
hint: discouraged. You can squelch this message by running one of the following
hint: commands sometime before your next pull:
hint:
hint: git config pull.rebase false # merge (the default strategy)
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only
hint:
hint: You can replace "git config" with "git config --global" to set a default
hint: preference for all repositories. You can also pass --rebase, --no-rebase,
hint: or --ff-only on the command line to override the configured default per
hint: invocation.
Already up to date.
/var/www/html/moodle$ sudo -u www-data php admin/cli/upgrade.php
A telepített 4.0+ (Build: 20220506) (2022041900.04) verziót nem szükséges frissíteni
sudo git status
On branch MOODLE_400_STABLE
Your branch is up to date with 'origin/MOODLE_400_STABLE'.
nothing to commit, working tree clean
version.php:
defined('MOODLE_INTERNAL') || die();
$version = 2022041900.04; // 20220419 = branching date YYYYMMDD - do not modify!
// RR = release increments - 00 in DEV branches.
// .XX = incremental changes.
$release = '4.0+ (Build: 20220506)'; // Human-friendly version name
$branch = '400'; // This version's branch.
$maturity = MATURITY_STABLE; // This version's maturity level.
MDL_Table:
select id,name,value from mdl_config where value like '202%';
+----+----------------+---------------+
| id | name | value |
+----+----------------+---------------+
| 30 | version | 2022041900.04 |
+----+----------------+---------------+
1 row in set (0.001 sec)
Nagyon köszönöm a segítséget!
Üdv!
Naív kérdés: backup volt? Amúgy miről frissítettél, mire?
Ugye a hiba szerint az update nem futott le teljesen vagy a kód egy része nem a friss verziójú. Apache error log van esetleg? Érdemes megnézni mit ír. Ehhez a fejlesztői hibaszűrést be kell kapcsolni.
Pl: a config.php-ben:
// Force a debugging mode regardless the settings in the site administration
// @error_reporting(E_ALL | E_STRICT); // NOT FOR PRODUCTION SERVERS!
// @ini_set('display_errors', '1'); // NOT FOR PRODUCTION SERVERS!
// $CFG->debug = (E_ALL | E_STRICT); // === DEBUG_DEVELOPER - NOT FOR PRODUCTION SERVERS!
// $CFG->debugdisplay = 1; // NOT FOR PRODUCTION SERVERS!
Én 3.11.5+-ról frissítettem 4.0+-ra. A https://download.moodle.org oldalról töltöttem le a forráskódot. Minden rendben ment.
Nálam a verzió (version.php):
$version = 2022041900.00; // 20220419 = branching date YYYYMMDD - do not modify!
// RR = release increments - 00 in DEV branches.
// .XX = incremental changes.
$release = '4.0 (Build: 20220419)'; // Human-friendly version name
$branch = '400'; // This version's branch.DB: SELECT id,name,value from mdl_config WHERE value like '202%'
id name value
9 backup_version 2022041900
27 version 2022041900
Előző frissítéskor minden rendben lefutott?
Üdv: Gábor
2022/05/07 19:47:20 [error] 6245#6245: *1500 FastCGI sent in stderr: "PHP message: Default exception handler: HIBA!!! A használt kód RÉGEBBI, mint az ezen adatbázisok létrehozásához használt verzió. Debug:
Error code: downgradedcore
* line 529 of /admin/index.php: moodle_exception thrown" while reading response header from upstream, client: IP cím, server: url cím, request: "GET /admin/index.php HTTP/2.0", upstream: "fastcgi://unix:/run/php/php7.4-fpm.sock:", host: "url cím", referrer: "https://url cím/login/index.php"
Üdv!
Még ilyet sikerült kinyerni:
select id,name,value from mdl_config where value like '202%';
+----+----------------+---------------+
| id | name | value |
+----+----------------+---------------+
| 8 | backup_version | 2022041900 |
| 30 | version | 2022041900.04 |
+----+----------------+---------------+
2 rows in set (0.001 sec)
Így ELVILEG van mentés. Eddig sose volt gondom a frissítéssel. A 3as verzióról is minden gond nélkül frissítettünk a 4esre. Heti frissítést szoktunk alkalmazni. Most is az lett volna. :( Esély van így a visszaállításra? Főleg a hogyanokat szeretném megkérdezni.
Üdv!
Az adatbázisban a backup_version arra utal, hogyha a kurzusról készített mentésbe milyen verziószámot írjon bele a Moodle. Moodle-ben be lehet kapcsolni automata mentést, ami a kijelölt kurzusokról biztonsági mentést készít. Ha ebben bíztál, akkor sajnos ez most rossz hír lehet.
Üzemeltetés első aranyszabálya: legyen biztonsági mentés. Frissítés előtt is.
Ha neked nincs biztonsági mentsed, akkor kérdezd meg a szolgáltatót, hogy van-e biztonsági mentés vagy egyéb visszaállítási pont!
Mit lehet most kezdeni? Jó kérdés. Először is mentés a jelenlegi állapotról (db, moodledata és wwwroot), aztán lehet próbálkozni.
Az Apache2 log nem volt valami beszédes. Én azért még átfutnám, hátha valami utal arra, hogy melyik modul nem frissült vagy hogy honnan jöhet a hiba.
Vagy próbálnám matchelni a verziókat az állományokban (minden modulnak, blocknak van version.php és lehet valamelyik nem frissült). Van nem standard plugin?
Vagy a Moodle oldalról töltött forráskódot raknám alá, vagy próbálnám matchelni a verziókat az állományokban vagy a db-ben.
Ha sikerül megoldani, akkor érdekelne mi lett végül.
Üdv: Gábor
Ui: van még HUP fórum?! :)
Üdv!
Siker, úgy tűnik!
A megoldás az lett ,hogy a version.php-ben és a mdl_config táblában a verziók korábbira lett visszaállítva:
sudo cat version.php:
$version = 2022041200.00; // .XX = incremental changes.
$release = '4.0 (Build: 20220412)';
//$branch = '400'; // This version's branch.
$branch = '400';
$maturity = MATURITY_STABLE; // This version's maturity level.
update mdl_config set value = 2022041200 where id = 30;
select * from mdl_config where value like '2022%';
+----+----------------+---------------+
| id | name | value |
+----+----------------+---------------+
| 8 | backup_version | 2022041900 |
| 30 | version | 2022041900.02 |
+----+----------------+---------------+
2 rows in set (0.001 sec)
Ezután lefuttattuk az upgrade.php-t: sudo -u www-data php admin/cli/upgrade.php Ez sikeresen lement és be is engedett a web-es felület és kiírta, hogy van frissítés. Ez sajnos a bigbluebuttonbn plugin mint elhasalt, mert nagyobb volt a verziószáma. Így ez modul el lett távolítva: sudo php uninstall_plugins.php --plugins=mod_bigbluebuttonbn,bigbluebuttonbn --run Az eltávolítás után a frissítés rendben lement, és a bigbluebuttonbn plugin megfelelő verziója is sikeresen feltelepült. A Portálkezelés --> Általános --> Értesítések résznél már azt írja a Moodle, hogy "Az Ön Moodle verziója a legfrissebb" Moodle 4.0+ (Build: 20220429)
Remélhetőleg tényleg a legfrissebb (heti) verzió van most így fent. :)
Nagyon köszönöm a sok sok segítséget!
U.I.: korábbi git pull -os szövegrészlet hol mutatta, hogy nincs minden rendben?
Új hiba sajnos! :(
2022/05/08 15:29:58 [error] 13742#13742: *1 FastCGI sent in stderr: "PHP message: PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 20480 bytes) in /webpages/www/html/moodle/cache/classes/helper.php on line 636" while reading response header from upstream, client: IP cím, server: url cím, request: "GET / HTTP/2.0", upstream: "fastcgi://unix:/run/php/php7.4-fpm.sock:", host: "url cím"
Pedig a php.ini-ben a memória limit nagyra van állítva: memory_limit = 1024M
Nálam még nem jött elő ilyen, pedig csak 256M van a PHP-nak.
Ahogy nézem a cache/classes/helper.php 636-ik sor a function hash_key()-ben van, azon belül a debugging van. Kikapcsoltad a hibaszűrést a frissítés után?
Ami még segíthet:
Cache-t töröld.
Kapcsold be a Teljesítményről szóló tájékoztatót a Portálkezelés / Fejlesztés / Hibaszűrés alatt! Megmutatja mi fogyaszt mennyit.
Lehet használni valami Cache rendszert, ami leveszi a PHP válláról a terheket. Én Memcache-det használok az egyik régebbi Moodle-nél. Az bevált. És a teljesítményen is javít. https://docs.moodle.org/400/en/Caching#Adding_cache_store_instances
Üdv:
Gábor
Gratula! És köszönet, hogy megosztottad!
Én nem használok gitet a frissítéshez.
Nem szenvedek vele tovább. :(
Lementettem mindent, amit csak lehetett (htlm, moodledata, moodle mappa stb.). Az adatbázis is ki lett mentve mysqldump-al (még a teljes adatbázist is). Remélhetőleg mindent sikerült lementeni. Újratelepítés lesz belőle. A Moodle visszaállításakor szükséges vmi figyelni (adatbázis, config.php stb.)?
Nagyon köszönöm!
Zsolti
Amire figyelni kell:
Minden amit a Moodle mond a release notes oldalon.
config.php (útvonalak, userek stb...)
PHP extension-ök be legyenek kapcsolva. PHP beállítások, post_max_size, upload_max, memory stb...
Ha te hozod létre az adatbázist, akkor szintén arra figyelni, amit a Moodle ajánl. (MySQL esetén: https://docs.moodle.org/400/en/MySQL)
Ha a domain változik, akkor van egy replace tool amit érdemes lefuttatni.
Üdv: Gábor
Egy gyors kérdés még.
mivel szoktad telepíteni/frissíteni a moodle-t, ha nem a git-el?
Nagyon köszönöm!
Egy jó kis mentő script Linux-ra:
https://gist.github.com/michael-milette/68cd1e3cb86e8b3b3ccb10de73a73ef5#file-moodle-backup-sh
Zsolti
Az oldschool módszerrel. Letöltöm a donwload oldalról. https://download.moodle.org/releases/latest/ . Persze nem hetenként frissítek.
Lehet, hogy a teszt rendszeren kipróbálom a git-es módszert.
Köszönjük a backup script megosztást! Az Azure-n snapshotolunk, másik tárhely szolgáltatónál a szolgáltató biztosít backupot a siteról. Régen meg saját script volt, amikor saját vason ment.
Üdv: Gábor
Üdv!
Killed
Sziasztok!
Az előzmények lapján összetettebb problémáról van szó, de a karbantartási mód be- és kikapcsolható parancssorból a moodle/admin/cli/maintenance.php segítségével:
https://docs.moodle.org/400/en/Administration_via_command_line#Maintenance_mode
Üdv.: Vágvölgyi Csaba
Üdv!
Sajnos amint bármelyik .php fájl futtatásra (pl: maintenance.php) kerül felzabálja az összes memóriát/cpu-t. Várni kell addig, amíg a Killed-el vissza nem jön a prompt.
Üdv!
Jól belecsaptál a lecsóba...
Ha jól gondolom FastCGI-t használsz. Kipróbáltad esetleg, hogy egy bármilyen más nem Moodle PHP is elvérzik-e (mondjuk egy sima phpinfo();)? Esetleg sima libapache-l próbáltad? Tudom nem túl fancy, de legalább ki lehet szűrni mi a probléma. Az mondjuk fura, hogy a log nem ír semmit. Vannak third-party modulok telepítve esetleg?
A 4-es Moodle-m egy tárhelyszolgáltatónál van, ott LiteSpeed PHP 7.3.27 alatt fut, minden gond nélkül. 256M memory_limit-tel.
Van amúgy egy másik aranyszabályunk, hogy ha kijön egy új főverziójú Moodle, akkor nem frissítünk egyből a production környezetben. Megvárjuk a X.1+-t. Addig kijönnek a kezdetleges hibák és a közösség visszajelzéseket is ad. Persze ez már késő bánat.
Gábor
Igen, sajnos! :(
Mivel nem szenvedtem vele tovább, ezért lett egy teljesen új telepítés (oprendszer szinten). Így elkezdtük az alapoktól. Azt gondoltunk, hogy minden happy lesz, de sajnos nem az lett. A "Moodle adatbázis frissítése most" gomb után eldobja a csatolt hibákkal (csatolmány). És ezek jönnek a mdl_tool_monitor_* tábláknál. A táblák átnevezései/törlései sajnos nem segítettek.
Köszönöm!
Frissítés...
Töröltük az összes mdl_tool_monitor_* táblákat ismét, és most sikeresen tovább ment (eddig). Kop-kop jelenleg.
drop table mdl_tool_monitor_events;
drop table mdl_tool_monitor_history;
drop table mdl_tool_monitor_rules;
drop table mdl_tool_monitor_subscriptions;
eddig megy rendesen! :)
De most már kínosan figyelünk a mentésre!
moodle: sudo tar -zcf "moodle_backup_$(date '+%Y-%m-%d_%H-%M-%S%z(%Z)').tar.gz" forrás mappa
moodledata: sudo tar -zcf "moodledata_backup_$(date '+%Y-%m-%d_%H-%M-%S%z(%Z)').tar.gz" forrás mappa
A fentiek csak példák/minták!
Az adatbázis dump még kerüljön bele a mentésbe!
Ennyi vesződség már megér egy prezentációt az idei MoodleMootra! :)
Gábor
:)
moodle: sudo tar -zcf "moodle_backup_$(date '+%Y-%m-%d_%H-%M-%S%z(%Z)').tar.gz" forrás mappa
moodledata: sudo tar -zcf "moodledata_backup_$(date '+%Y-%m-%d_%H-%M-%S%z(%Z)').tar.gz" forrás mappa
adatbázis: sudo mysqldump -u root -p moodledb | gzip -c | cat > moodledb_backup_$(date '+%Y-%m-%d_%H-%M-%S%z(%Z)').sql.gz
adatbázis: sudo mysqldump -u root -p moodledb > moodledb_backup_$(date '+%Y-%m-%d_%H-%M-%S%z(%Z)').sql
De ezek csak minták/példák.