en fresh install il met 256
Ok, je vais faire pareil. Avec 1Gb de mémoire vive c’est un peu chaud mais ça devrait passer !
Un raspi 2 avec une debian10 ou même avec une v4, je trouve que cela fait vraiment juste.
Un 3 devient le minimum je pense
Aucun lien avec la ram … ça prends sur le filesystem root
root@jeedom:/tmp# df /tmp
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
/dev/sda1 16447356 6373852 9218312 41% /
EDIT : Quoique j’ai un doute…
EDIT2 : Effectivement c’est en RAM … 
root@jeedom:/tmp# df /tmp/jeedom
Sys. de fichiers blocs de 1K Utilisé Disponible Uti% Monté sur
tmpfs 262144 5320 256824 3% /tmp/jeedom
C’est bête ça sert à rien de mettre les fichiers de mise à jour dans le cache … Il servent pas aussi souvent que ça !
Bon, il y a quand même un soucis, même avec 256Mb de tmp:
guihome@jeedom:~ $ sudo df -Bm
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 20031M 4699M 14292M 25% /
devtmpfs 459M 0M 459M 0% /dev
tmpfs 464M 0M 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5M 1M 5M 1% /run/lock
tmpfs 464M 0M 464M 0% /sys/fs/cgroup
tmpfs 256M 138M 119M 54% /tmp
/dev/mmcblk0p1 41M 23M 19M 56% /boot
tmpfs 93M 0M 93M 0% /run/user/33
tmpfs 93M 0M 93M 0% /run/user/1001
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…
Oh, je suis plein d’espoir !
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
guihome@jeedom:~ $ sudo df -Bm
Filesystem 1M-blocks Used Available Use% Mounted on
/dev/root 20031M 4628M 14364M 25% /
devtmpfs 459M 0M 459M 0% /dev
tmpfs 464M 0M 464M 0% /dev/shm
tmpfs 464M 13M 452M 3% /run
tmpfs 5M 1M 5M 1% /run/lock
tmpfs 464M 0M 464M 0% /sys/fs/cgroup
tmpfs 256M 138M 119M 54% /tmp
/dev/mmcblk0p1 41M 23M 19M 56% /boot
tmpfs 93M 0M 93M 0% /run/user/33
tmpfs 93M 0M 93M 0% /run/user/1001
Bonjour,
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/.
Il est bien présent, je confirme !
mysqldump Ver 10.16 Distrib 10.1.47-MariaDB, for debian-linux-gnueabihf (armv7l)
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.
Je comprends ton point de vue, je suis comme toi un utilisateur Jeedom et oui tout n’est pas parfait. Il y a des choses surprenantes et qui fonctionne moyennement, mais il y a aussi beaucoup de chose qui fonctionne super.
Du coup je ne sais pas vraiment comment aider.
J’ai quand même une dernière idée, mettre /tmp/jeedom sur disque mais mettre /tmp/jeedom/cache en tmpfs. Avec cette solution le cache sera bien en RAM pour profiter des performances et le reste du tmp sera sur disque pour avoir de la place pour les actions de sauvegarde et autre.
Mais sinon j’avoue être à court d’idée/solution pour résoudre le soucis.
Moi, je peux bien, mais je ne sais pas comment faire! 
C’est il me semble hardcodé, c’est pas quelque chose que je peux configurer.
Mon nettoyage de base de données m’a fait perdre 1Mb.
EDIT : cette solution génére une erreur au démarrage de Jeedom (voir post en dessous)
Normalement dans le fichier /ets/fstab tu dois avoir une ligne type (il me semble car je ne l’ai pas chez moi)
tmpfs /tmp/jeedom ....
Pour moi il suffit de modifier la ligne en
tmpfs /tmp/jeedom/cache ....
Il ne faut surtout pas modifier d’autre ligne sinon ça boot plus bien ou pas du tout en fait.
Après reboot, car si tu change à chaud Jeedom ne devrai pas apprécier (désolé pour ton uptime, je sais que tu reboot rarement ton PI, comme tu le dis dans tes vidéos 
).
Pour moi il n’y a pas de risques au pire le tmpfs ne se monte pas et utilise le disque à la place. Tu pourra faire un rollback de la modification. J’espère vraiment ne pas faire planter ton Jeedom, si tu as un Jeedom de test essai d’abord dessus pour confirmer mes dires. La confiance n’exclut pas le contrôle. En plus il est tard et je fatigue. Vérifie stp avant (en testant), histoire que tu ne soit pas dans l’embarra.
Ensuite petit df -h pour vérifier que tout est comme attendu.
je vais garder cette option sous le coude, à la prochaine maj de core, si ça ne passe pas, je remonterai la problématique de manière officielle au support, et suivant leur réponse, je pense que je partirai sur la solution que tu proposes 
Bonjour,
Pour information j’ai testé sur mon Jeedom de test la solution que j’ai proposée.
Bon point de vue Linux pas de soucis pour le faire, point de vue Jeedom ça pose souci.
J’ai une erreur lors du démarrage de Jeedom
Erreur sur la restauration du cache : Erreur sur rm -rf /tmp/jeedom/cache;mkdir /tmp/jeedom/cache;cd /tmp/jeedom/cache;tar xfz /var/www/html/core/class/../../cache.tar.gz;chmod -R 777 /tmp/jeedom/cache 2>&1 > /dev/null; valeur retournée : 1. Détails : chmod: modification des droits de '/tmp/jeedom/cache': Opération non permise
Au démarrage Jeedom essai de supprimer le dossier cache, mais c’est impossible puisqu’il est défini en point de montage. Après il semble que le cache est quand même bien restauré, mais sur un Jeedom de prod avoir un message au boot c’est moche.
Du coup ce n’est pas vraiment une bonne idée de faire ce que j’ai proposé.
C’est noté ! je ne fais pas, merci de me l’avoir confirmé 
Le truc c’est que ça ne résout pas le souci initial.
Bah non, je sais bien, lors de la prochaine maj de core je risque d’être un peu en galère.
Mais si c’est le cas, je soumettrai un incident, ça me permettra de parler du support jeedom en vidéo ! ^^
Je n’ai à ce jour plus de problème, et pourtant je n’ai mis à jour ni l’OS, ni jeedom (depuis l’upgrade donc). Je n’ai pas fait de changement autre que l’augmentation du tmp à 256Mb, suivi de plusieurs reboots, et pourtant ce soir la MAJ du plugin philipsHue brillamment corrigé par Loïc est passé comme une lettre à la poste !
Et j’ai horreur de ces problèmes qui se résolvent seuls, je suis certain que tôt ou tard ça va revenir… mais pour l’instant, c’est bon, je peux faire des mises à jour de manière classique, en mettant à jour Core en même temps !
[START UPDATE]
****Update from 4.0.61 (2020-12-12 20:46:21)****
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-12 20:46:31***************
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-4.0.61-2020-12-09-07h15.tar.gz | OK
Nom de la sauvegarde : /var/www/html/core/php///backup/backup-GUIHome-4.0.61-2020-12-12-20h46.tar.gz
Vérification des droits sur les fichiers | OK
Envoi l'évènement de fin de sauvegarde | OK
Durée de la sauvegarde : 197s
***************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-12 20:49:49-- 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-12 20:49:49-- 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: 44976484 (43M) [application/zip]
Saving to: '/tmp/jeedom/install/jeedom_update.zip'
0K 6% 4.43M 9s
3072K
. 13% 5.09M 8s
6144K 20% 4.90M 7s
9216K
27% 4.83M 6s
12288K 34% 4.62M 6s
15360K
41% 4.83M 5s
18432K 48% 5.10M 5s
21504K 55% 4.73M 4s
24576K 62% 4.87M 3s
27648K
. 69% 4.74M 3s
30720K 76% 4.75M 2s
33792K
83% 4.83M 1s
36864K 90% 4.43M 1s
39936K
97% 5.00M 0s
43008K 100% 5.38M=8.9s
2020-12-12 20:49:58 (4.80 MB/s) - '/tmp/jeedom/install/jeedom_update.zip' saved [44976484/44976484] | OK
Cleaning folders | OK
Create temporary folder | OK
Unzip in progress | OK
Clean temporary files (tmp) | OK
Disable all task
.
| OK
Disable all scenario | OK
Moving files | OK
Remove temporary files | OK
Check jeedom consistency
[START CONSISTENCY]
[START CHECK AND FIX DB]
[END CHECK AND FIX DB]
Check jeedom database | OK
Check filesystem right | OK
[END CONSISTENCY] | OK
Check update | OK
***************Jeedom is up to date in 4.0.61***************
***************Update plugins***************
[2020-12-12 20:50:29][ALERT] : Début de la mise à jour de : philipsHue
[2020-12-12 20:50:29][ALERT] : Action de pré-update
[2020-12-12 20:50:29][ALERT] : | OK
[2020-12-12 20:50:29][ALERT] : Téléchargement du plugin
[2020-12-12 20:50:29][ALERT] : Téléchargement de philipsHue
[2020-12-12 20:50:29][ALERT] : URL https://market.jeedom.com/core/php/downloadFile.php?id=190&version=stable&jeedomversion=4.0.61&hwkey=91f42345908954d85077bcf109aeaa91548f0d89&username=guipom&password=8b6bec7e53de45ed21c1204433bbff3b4373ec1a&password_type=sha1
--2020-12-12 20:50:30-- https://market.jeedom.com/core/php/downloadFile.php?id=190&version=stable&jeedomversion=4.0.61&hwkey=91f42345908954d85077bcf109aeaa91548f0d89&username=guipom&password=8b6bec7e53de45ed21c1204433bbff3b4373ec1a&password_type=sha1
Resolving market.jeedom.com (market.jeedom.com) 51.210.253.116, 51.178.69.128
Connecting to market.jeedom.com (market.jeedom.com)|51.210.253.116|:443 connected.
HTTP request sent, awaiting response 200 | OK
Length: unspecified [application/octet-stream]
Saving to: '/tmp/jeedom/market/philipsHue.zip'
0K 1.65M
50K 3.67M
100K 3.90M
150K 2.65M
200K 2.88M
250K 2.58M
300K 2.88M
350K 2.64M
400K 2.91M
450K 3.16M
500K 4.22M
550K 4.05M
600K 4.32M
650K 3.77M
700K 4.41M
750K 3.97M
800K 4.48M
850K 4.03M
900K 4.31M
950K 3.69M
1000K 4.02M
1050K 3.87M
1100K 4.08M
1150K 3.84M
1200K 4.31M
1250K 3.97M
1300K 4.31M
1350K 3.95M
1400K 4.23M
1450K 4.01M
1500K 4.23M
1550K 3.98M
1600K 4.31M
1650K 4.04M
1700K 2.37M
1750K 3.20M
1800K 2.93M
1850K 2.98M
1900K 3.26M
1950K 2.87M
2000K 3.35M
2050K 2.29M
2100K 2.57M
2150K 2.83M
2200K
3.49M
2250K 2.99M
2300K 2.96M
2350K 2.23M
2400K 4.36M
2450K 441G=0.7s
2020-12-12 20:50:30 (3.34 MB/s) - '/tmp/jeedom/market/philipsHue.zip' saved [2509037]
[2020-12-12 20:50:30][ALERT] : | OK
[2020-12-12 20:50:30][ALERT] : Décompression du zip
[2020-12-12 20:50:31][ALERT] : | OK
[2020-12-12 20:50:31][ALERT] : Post-installation de philipsHue
[2020-12-12 20:50:31][ALERT] : Supression des fichiers inutiles
[2020-12-12 20:50:34][ALERT] : | OK
***************Update plugin successfully***************
Check update | OK
Enable scenario : | OK
Enable task : | OK
Launch cron dependancy plugins | OK
Send end of update event | OK
Update duration : 255s
[END UPDATE SUCCESS]