Je viens de procéder à la mise à jour en V4.0.61 sur mon RPI 2B de prod (sous Debian 9.13).
J’ai quelques soucis, mais je vais procéder du plus critique au plus cosmetique. Mon problème majeur: le dossier /tmp qui sature vite. Et qui crée des erreurs !
Log :
[START UPDATE]
****Update from 4.0.61 (2020-12-04 00:46:48)****
Parameters : {"preUpdate":"0","backup::before":"1","plugins":"1","core":"1","force":"0","update::reapply":""}
Send begin of update event | OK
Check update | OK
Check rights | OK
[START BACKUP]
***************Start of Jeedom backup at 2020-12-04 00:46:54***************
Envoi l'évènement de début de sauvegarde | OK
Vérification des droits sur les fichiers | OK
Vérification de la base de données | OK
Sauvegarde la base de données | OK
Persistance du cache : | OK
Création de l'archive | OK
Nettoyage de l'ancienne sauvegarde | OK
Limitation de la taille des sauvegardes à 500 Mo
Supprime : /var/www/html/core/php///backup/backup-GUIHome-3.3.54-2020-12-03-23h40.tar.gz | OK
Nom de la sauvegarde : /var/www/html/core/php///backup/backup-GUIHome-4.0.61-2020-12-04-00h46.tar.gz
Vérification des droits sur les fichiers | OK
Envoi l'évènement de fin de sauvegarde | OK
Durée de la sauvegarde : 200s
***************Fin de la sauvegarde de Jeedom***************
[END BACKUP SUCCESS]
Download url : https://github.com/jeedom/core/archive/V4-stable.zip
Download in progress
--2020-12-04 00:50:15-- https://github.com/jeedom/core/archive/V4-stable.zip
Resolving github.com (github.com) 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443 connected.
HTTP request sent, awaiting response 302 Found
Location: https://codeload.github.com/jeedom/core/zip/V4-stable [following]
--2020-12-04 00:50:15-- https://codeload.github.com/jeedom/core/zip/V4-stable
Resolving codeload.github.com (codeload.github.com) 140.82.121.9
Connecting to codeload.github.com (codeload.github.com)|140.82.121.9|:443 connected.
HTTP request sent, awaiting response 200 | OK
Length: 44976464 (43M) [application/zip]
Saving to: '/tmp/jeedom/install/jeedom_update.zip'
0K 6% 3.99M 10s
3072K 13% 4.39M 9s
6144K
20% 4.74M 8s
9216K 27% 4.62M 7s
12288K 34% 3.30M 7s
15360K 41% 3.32M 6s
18432K 48% 3.57M 6s
21504K
55% 4.14M 5s
24576K 62% 5.03M 4s
27648K 69% 5.03M 3s
30720K
. 76% 4.98M 2s
33792K 83% 4.82M 2s
36864K 90% 4.00M 1s
39936K
97% 3.98M 0s
43008K 100% 5.74M=10s
2020-12-04 00:50:25 (4.22 MB/s) - '/tmp/jeedom/install/jeedom_update.zip' saved [44976464/44976464] | OK
Cleaning folders | OK
Create temporary folder | OK
Unzip in progress | OK
Error during update : Error no more free space on /tmp/jeedom_unzip. Free space : 0Details : Array
(
)
[END UPDATE ERROR]
PHP Fatal error: Uncaught Exception: Error no more free space on /tmp/jeedom_unzip. Free space : 0 in /var/www/html/install/update.php:174
Stack trace:
#0 {main}
thrown in /var/www/html/install/update.php on line 174
S’il y a une mise à jour du core son bouton n’est pas au même endroit => tout en haut à droite.
Pour infos, sur les nouvelles installations la taille de tmp est passée à 256mo
Oui oui je le vois bien, je le lis aussi. Mais je t’assure, il n’y a que deux plugins a mettre a jour dans l’interface, je les montre, et core n’est pas sélectionné.
J’ai lancé un reboot, tant pis pour l’uptime, pour que ça parte sur une base saine.
Ca ne parle pas de mettre à jour core !
Non cela ne parle pas de mettre a jour le core car il n’y a pas de nouvelle version
Mais si tu laisses mettre a jour le core coché, il va le mettre et cela te permet de récupérer une version que Loic dans laquelle Loic a poussé un correctif comme il le fait parfois pour qu’on l’aie de suite et sans attendre une sortie de version
Vous me conseillez quoi comme taille de /tmp, parce qu’apparement, avec la v4, la taille par défaut ne passe plus (128Mb). Je ne pense pas que ça fasse partie de la config jeedom, vu que je suis en DIY, mais j’ai pas vu cette info !
2020-12-04 11:44:09 (4.01 MB/s) - '/tmp/jeedom/install/jeedom_update.zip' saved [44976484/44976484] | OK
Cleaning folders | OK
Create temporary folder | OK
Unzip in progress
Error during update : Can not unzip fileDetails : Array
(
)
[END UPDATE ERROR]
PHP Fatal error: Uncaught Exception: Can not unzip file in /var/www/html/install/update.php:166
Stack trace:
#0 {main}
thrown in /var/www/html/install/update.php on line 166
Evidemment, vous me direz « mais décoche c’est saleté de case à cocher de mise à jour de core ». Mais je me dis que si elle est cochée, c’est pour une raison, et si ça marche pas, c’est pour une autre raison !
Et j’ai bien unzip: unzip is already the newest version (6.0-21+deb9u2).
La case à cocher n’est pas obligatoire, c’est en fonction de ta dernière motif sur la config.
Commence par mettre à jour les plugins (sans le core) c’est pas perdu…
Uniquement que les deux plugins, voici ce que ça donne:
***************Start of Jeedom backup at 2020-12-04 11:51:43***************
Envoi l'évènement de début de sauvegarde | OK
Vérification des droits sur les fichiers | OK
Vérification de la base de données | OK
Sauvegarde la base de donnéesmysqldump: Error: 'Can't create/write to file '/tmp/#sql_2b6_2.MAI' (Errcode: 28 "No space left on device")' when trying to dump tablespaces
mysqldump: Couldn't execute 'show fields from `cache`': Can't create/write to file '/tmp/#sql_2b6_0.MAI' (Errcode: 28 "No space left on device") (1)
Erreur durant la sauvegarde : Echec durant la sauvegarde de la base de données. Vérifiez que mysqldump est présent. Code retourné : 2Détails : Array
(
[0] => Array
(
[file] => /var/www/html/core/class/jeedom.class.php
[line] => 676
[function] => require_once
)
[1] => Array
(
[file] => /var/www/html/install/update.php
[line] => 100
[function] => backup
[class] => jeedom
[type] => ::
)
)
[END BACKUP ERROR]
Error during update : Echec durant la sauvegarde de la base de données. Vérifiez que mysqldump est présent. Code retourné : 2Details : Array
(
[0] => Array
(
[file] => /var/www/html/core/class/jeedom.class.php
[line] => 676
[function] => require_once
)
[1] => Array
(
[file] => /var/www/html/install/update.php
[line] => 100
[function] => backup
[class] => jeedom
[type] => ::
)
)
[END UPDATE ERROR]
PHP Fatal error: Uncaught Exception: Echec durant la sauvegarde de la base de données. Vérifiez que mysqldump est présent. Code retourné : 2 in /var/www/html/install/backup.php:115
Stack trace:
#0 /var/www/html/core/class/jeedom.class.php(676): require_once()
#1 /var/www/html/install/update.php(100): jeedom::backup()
#2 {main}
thrown in /var/www/html/install/backup.php on line 115
Il semble qu’il manque mysqldump au vu des logs fournis, du coup le backup de la BDD ne fonctionne pas et ne se finit pas correctement.
Peux-tu confirmer que mysqldump est bien présent sur Debian.
mysqldump -V
Sinon pour /tmp/ qui est monté via TMPFS, tu peux commenter la ligne (TMPFS utilise de la RAM, si plus de RAM il swap) dans /etc/fstab. Dans ce cas le /tmp/ ne sera que sur ton disque sans utiliser de la RAM et du coup la limite de taille (espace disponible) est celle du / dans ton cas ~14Go. A faire en connaissance de cause.
Mon install Jeedom n’utilise pas de TMPFS pour /tmp/.
Je viens de relire les logs fournis. J’avais mal lu, mais il y a eu un soucis d’espace disque sur /tmp « encore ».
Du coup soit tu as une install Jeedom « énorme » qui explique un backup important ou beaucoup d’historique.
Du coup soit faire le tri dans les historiques pour gagner de la place, soit avoir un /tmp plus grand, soit mettre /tmp sur disque plutôt que tmpfs (comme je disais dans mon précédent post).
Le problème c’est que c’est une soucis de v4. Je n’ai jamais, de près ou de loin, eu le moindre soucis de backup pendant mes updates. Et je n’étais qu’à 128Mb.
Je pense plutôt à bonne très mauvaise idée. Utiliser tmp pour faire les backups et accélérer les choses. Ca marche quand tmp n’est pas un soucis. Ca marche quand on n’a une machine toute neuve. Si on a jeedom qui tourne depuis 2013 (? je crois) alors ça ne marche pas vraiment. Du moins c’est la conclusion à laquelle j’arrive.
Pour info mes backups faisaient 90Mb en V3. Avec la V4, ils sont passés à 110Mb.
Je ne fais pas de nettoyage, parce que je laisse faire les outils jeedom, et je conserve surtout tous les relevés de température, chauffe, humidité et compagnie, pour comparer année à année, mois à mois, et optimiser mon logement.
Pour l’instant je ne considère pas que j’ai « beaucoup » de données. C’est pas une installation toute propre, mais c’est je trouve tout à fait raisonnable.
Et je ne peux pas mettre tmp sur disque, surtout pas, ce serait une catastrophe, le cache jeedom est dessus !
Ah, et si ça a toujours été le cas cette utilisation intensive de tmp, alors soit je suis hyper chanceux jusqu’à présent, soit il y a quelque chose d’autre que je ne m’explique pas !
Et j’ai lancé un petit cleandb au cas où, pour voir si ça allège un peu la sauvegarde.
