En continuant sur la piste je trouve ceci dans /var/log
ces deux fichiers ont la même date et la même heure que les 2 derniers redémarrage
je ne sais pas comment rapatrier ces 2 fichiers sur mon PC
Intrigant ça, tu devrais peut-être mettre en œuvre ce tuto pour avoir les infos de bannissement dans le centre de message.
Ta jeedom est en ip fixe sur ton réseau ?
Bonjour,
C’est normal. C’est lié au service qui te protège en cas de tentatives répétées de connexion infructueuses.
Les logs « tournent » au redémarrage.
Sans les rapatrier tu peux les ouvrir avec nano fail2ban.log et copier peut-être pas tout mais au moins les dernières données. En tout cas tu pourras lire le contenu
Pas sur qu’il voit quelque chose
Fail2ban fait un log rotate au démarrage de mémoire donc bon voir ou pas des ip bannies ne donnera pas la cause !
Pour les rapatrier depuis un PC, au lieu de se connecter avec putty, utiliser winscp pour se connecter et ca permet de choisir quoi et ou le rapatrier
last reboot en commande sous linux donne quoi ?
Là tu devrais voir ce que tu vois dans la date jeedom déjà !
Y a aussi who -b
Il faut plutot regarder un fichier /var/log/kern.log pour faire un diagnostic du reboot !!
Rechercher l’heure de reboot (vous devriez à ce moment là avoir enormement de lignes (toutes les actions effectuées au moment du reboot), et juste avant les derniers messages avant le reboot
(je ne vois pas bien en quoi le fail2ban aurait un quelconque lien avec le reboot. Les dates qui coincident sont juste liées au logrotate fait au moment du reboot)
Norbert
1 « J'aime »
Y a aussi le syslog peut être bref les log dans /var/log lol
1 « J'aime »
Il est pas réglé par défaut sur 4 semaines le rotate ? Il me semblait me rappeler de ça 
last reboot donne :
reboot system boot 3.16.85+ Thu Jan 1 00:00 still running
reboot system boot 3.16.85+ Thu Jan 1 00:00 still running
reboot system boot 3.16.85+ Thu Jan 1 00:00 still running
reboot system boot 3.16.85+ Thu Jan 1 00:00 - 17:32 (19659+17:32)
reboot system boot 3.16.85+ Thu Jan 1 00:00 - 17:32 (19659+17:32)
reboot system boot 3.16.85+ Thu Jan 1 00:00 - 17:32 (19659+17:32)
etc…
who -b donne « system boot Jan 1 00:00 »
ma jeedom est distante
pour le moment je n’arrive pas à utiliser winscp en ftp
j’obtiens << Expiration du délai détectée ! (Connexion de contrôle)
La connexion a échoué. >>
avec putty en ssh ça donne << remote side unexpectedly closed netwok connection >>
=> je réessaye demain
bonne soirée, merci pour vos indications
Heu ssh et winscp c’est en port 22, donc en remote si tu n’as pas prévu c’est impossible !
Ta jeedom est pas a l’heure si tu repars toujours de 00:00 le 1er janvier
Y a pas une pile dans ta box pour garder ce genre d’info ?
Hello, attention en passant ce genre de batterie n’est pas toujours fait pour cette utilisation, il faut évidemment qu’elle ait le pass-through mais ça ne suffit pas, je ne me rappelle plus du nom mais il y a une autre feature pour s’assurer qu’elle ne prendra pas feu…
ok port 22 c’est noté; la jeedom en local est en ip fixe, en remote le port 22 n’est pas dans la plage des ports accessibles, je redirige sur la freebox 42122 sur 22
avec winscp en ftp cela donne << Expiration du délai détectée ! (Connexion de contrôle) La connexion a échoué. >>
avec putty, cela donne << Network error: connection timed out >>
je ferai d’autres essais
Je n’ai pas souvenir qu’il y ait une pile dans la Jeedom Smart.
Last news : après enquête menée auprès d’Enedis, il s’avère que mes 2 dernières microcoupures sont dues au réseau, durée environ 400ms, pour cause de défaut d’élagage sur certaine(s) parties aériennes.
1er constat : la microcoupure traverse la powerbank (et on peut donc vraiment parler de pass through)
2ème constat
oui c’est bientôt Noël et Vendredi Noir, je vais remettre en service un onduleur et aussi demander Luna au papa Noël (pour une 2ème installation domotique).
Vous confirmez qu’avec Luna, on n’a pas besoin d’onduleur ?
3ème constat: je vais continuer d’essayer winscp et putty, en y allant graduellement : d’abord sur place en local puis en remote
encore merci pour toutes vos interventions
Quelque part ça me rassure.
Un onduleur dont c’est le job c’est plus fiable !
Bonsoir,
Merci pour ces nouvelles du passe trou 
oui un onduleur est essentiel il gère aussi les surtensions et permet de sauvegarder plus efficacement l’électronique. Les prix ont drôlement baissé je passe sur ceux à 50 euros, mais aux alentours de 100 on commence à trouver des marques plus connues.
Pour la luna, n’en ayant pas, je ne sais pas te répondre mais perso je l’ondulerais quand même.
Bonne soirée
Dans la FAQ, que l’on trouve dans la doc (https://doc.jeedom.com/fr_FR/core/4.4/faq) on trouve cela :
J’ai l’erreur suivante : SQLSTATE[HY000] [2002] Can’t connect to local MySQL server through socket ‘/var/run/mysqld/mysqld.sock’
ce qui arrive souvent suite à un arrêt non propre de Jeedom (coupure de courant)
La BDD c’est le cœur ! Et ça n’aime pas les coupures de courant !
Donc j’estime que tout système doit être ondulé et muni d’un mécanisme qui arrête proprement la machine si le courant n’est pas revenu et que l’onduleur arrive au bout
Je cite << La JEEDOM LUNA est équipée d’une batterie de secours intégrée. Ainsi en cas de coupure d’électricité, elle reste opérationnelle. Cela lui évite aussi un risque de dysfonctionnement après une coupure brutale. >>
J’espère simplement qu’il existe des évènements tels que « external power down » et « external power up »
Bonne journée
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.