J’utilise le plugin Cloudsyncpro depuis 2 ans sans problème avec synchronisation de mes backup Jeedom et copie des captures Caméra.
Depuis plusieurs jours je me suis rendu compte que la synchronisation du Backup ne s’effectuait plus
J’ai vidé le répertoire sur DropBox et relancé, je constate que seul le fichier ‹ .htaccess › est copié puis arrêt en erreur.
J’ai essayé ave d’autre répertoires source, cela fonctionne (donc pas un problème DropBox), j’ai l’impression que seul le folder ‹ backup › de Jeedom pose problème.
J’avais installé le 27/12 toutes les mises à jour Raspbian, est-ce cela le problème ?
Voici les infos
On peut voir que l’erreur apparaît après une minute environ, un peu long pour copier uniquement le fichier ‹ .htaccess ›
Merci d’avance si vous pouviez m’aider sur ce sujet
Les infos sur mon environnement
RaspBerry PI3B+
Connecté réseau RJ45
Internet 800MB/100MB
Jeedom 4.0.61 avec tous les plugin à jour en mode Stable
J’ai installé la Beta même résultat
Voici les Logs cloudsyncpro.txt (4,8 Ko) cloudsyncpro_3605.txt (461 Octets)
Egalement capture écran du folder Backup et sur Dropbox
J’avais supprimé les fichiers dans Dropbox avant de refaire l’essai.
Peux-tu temporairement me fournir un accès à ton installation Jeedom que je puisse comprendre le problème ? Tu peux m’envoyer les informations en MP.
Pour information, je suis la personne en charge de ce plugin
Je pense avoir compris le problème… qui est indépendant du plugin et lié à la consommation mémoire.
Pour test, j’ai lancé manuellement une synchronisation avec un index de parallélisme de 1 (un seul transfert à la fois) et tout fonctionne parfaitement bien. Par défaut, l’index de parallélisme est de 4 (4 transfert en parallèle) ce qui induit une consommation mémoire plus importante.
Vu la configuration de ton installation, ces 4 transferts en parallèle ne peuvent s’exécuter (manque de mémoire) et l’OS supprimer le processus le plus consommateur d’ou l’arrêt brutal lors de l’upload.
Voici les logs systèmes :
Jan 2 16:01:19 jeedom kernel: [594914.023297] ntpd invoked oom-killer: gfp_mask=0x100cca(GFP_HIGHUSER_MOVABLE), order=0, oom_score_adj=0
Jan 2 16:01:20 jeedom kernel: [594914.023322] CPU: 1 PID: 1764 Comm: ntpd Tainted: G C 5.4.79-v7+ #1373
Jan 2 16:01:20 jeedom kernel: [594914.023327] Hardware name: BCM2835
[...]
Jan 2 16:01:20 jeedom kernel: [594914.025677] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/,task=rclone,pid=8884,uid=33
Jan 2 16:01:20 jeedom kernel: [594914.177418] oom_reaper: reaped process 8884 (rclone), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
Au vu de la page santé (1 Go de mémoire), je te recommande d’augmenter la mémoire disponible surtout si tu veux pérenniser ton installation.
Pour information et si utilisation du plugin chaque jour, tu ne devrais plus rencontrer à nouveau ce problème car il n’y aura qu’un seul fichier à transférer chaque jour donc un seul upload en parallèle.
C’est un contournement bien sur et non une solution.
Pour information, la prochaine version du plugin permettra de configurer ce paramètre.
Merci @thanaus pour ton support rapide sur ce point.
Je n’aurais jamais pensé à ce type de problème.
Je vais donc prévoir à passer de mon PI3B+ à un PI 4 avec 2GB de mémoire cela permettra d’avoir de la marge pour pérenniser mon installation qui date déjà de 2 ans.
Quand penses tu publier la prochaine version du plugin ?
Salut à tous pour le retour d’expérience, car cela peut servir quand on se retrouve en limite de capacité de son Hardware sans pouvoir l’identifier (si l’on est un utilisateur sans expertise système).
Je viens de remplacer mon RaspBerry PI3B par un PI4 avec 2GB de mémoire.
Plus aucun problème avec la fonction de synchronisation.
Je n’avais aucun doute sur ta réponse @thanaus
Merci encore pour le support apporté
