Il y a peu de chances que ce soit ça alors.
Vous avez essayé de repartir sur un raspbian neuf ?
Non connexion ethernet pour le PI et connexion fibre pour la box.
La connexion internet est monitorée. Je reçois un SMS lorsqu’il y a une coupure.
Le seul souci, c’est le redémarrage du Pi sans connexion internet.
Là, on a un truc qui force le redémarrage.
Trop de truc qui tourne dessus, on n’arrête pas la prod !
Une machine tout en un, c’est bien, c’est pratique. Mais quand, il faut réparer des trucs, c’est compliqué de ne pas arrêter ce qui marche.
1 « J'aime »
https://blog.vincentdeniau.fr/articles/synchroniser-heure-raspberrypi-fiable
Ca vaut peut être le coup d’essayer…
Re-essayez de faire ça aussi , en parcourant le net j’ai vu que certains avaient eu ce problème, rapsi-config avait « oublié » la timezone
sudo raspi-config- Select
Internationalisation Options - Select
I2 Change Timezone - Select your Geographical Area
- Select your nearest City
- Select
Finish - Select
Yesto reboot now
1 « J'aime »
Ouais, j’avais essayé
Current default time zone: 'Europe/Paris'
Local time is now: Wed Nov 25 20:44:30 CET 2020.
Universal Time is now: Wed Nov 25 19:44:30 UTC 2020.
J’étais déjà passé par là, tout est déjà OK
Ton wifi est connecté sur le pi ?
Une autre personne a eu un souci de double fichier de conf:
Also had problems with ntpd syncing, got an offset of -7294 seconds after reboot and ntpd was not able to sync up. Think the limit for ntpd is 127 seconds. Had the same problem on raspberrypi and bananapi. The solution was the same on both. Here i am using Raspian_For_BananaPi_v3.1 on a BananaPi. The reason for the -7294 sec offset was that the /etc/init.d/ntp script was starting the /var/lib/ntp/ntp.conf.dhcp as the config file for ntpd (-c), this file was using 192.168.0.1 as timerserver. Which is my internet modem with a timeserver which had -7294 seconds offset. Complained to my internet provider, but has not got any feedback yet.
Just commented out three lines in /etc/init.d/ntp to fix the problem:
# if [ -e /var/lib/ntp/ntp.conf.dhcp ]; then
# NTPD_OPTS="$NTPD_OPTS -c /var/lib/ntp/ntp.conf.dhcp"
# fi
then ntpd will use the default config file /etc/ntp.conf.
Then I just changed from debian to local (no) pools in /etc/ntp.conf:
# pool: <http://www.pool.ntp.org/join.html>
server 0.no.pool.ntp.org iburst
server 1.no.pool.ntp.org iburst
server 2.no.pool.ntp.org iburst
server 3.no.pool.ntp.org iburst
did a reboot and ntpd started to work.
bananapi@Banana2 ~ $ sudo ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp2.interpost. 139.112.153.51 2 u 66 1024 373 15.085 -1.769 2.660
*ntp-ext.cosng.n 146.213.3.181 2 u 88 1024 377 13.929 -3.778 4.319
+2a02:20c8:1981: 192.36.144.22 2 u 1021 1024 377 12.678 -2.927 2.763
-ntp1.enuv.eu 192.36.143.150 2 u 194 1024 377 11.598 6.200 106.058
The ntpd deamon is using the timeserver with a * in front, with 3.778 ms offset. It will take some hours before the offset is below 10 ms offset.
Je dirais que oui car le Pi est connecté en double sur la box.
Le Wi-Fi est configuré. Si je débranche le câble ethernet, le Wi-Fi prend le relais.
Remarque, je n’ai plus le service ntpd que j’ai viré comme indiqué dans ton lien. Donc, je n’ai plus les fichiers pour faire les modifs que tu cites. 
Depuis le début, j’ai fait des modifs dans tous les sens concernant le NTP. Je n’ai donc plus trop une config de référence.
Le problème, c’est qu’il y a un truc qui entraîne un reboot mal propre.
Un débranchement de l’alim (c’est pourtant brutal aussi) et tout repart bien, donc pas de souci de re-synchro après redémarrage. J’ai aussi coché l’option d’attendre le réseau au démarrage.
Merci @lone pour tes idées
Essaye sans le wifi, la double connexion entraîne des problèmes
Au prochain plantage, je le mettrai en Wi-Fi plutôt que de le désactiver. Mais, je ne vois pas trop le rapport.
Ntp se sert du réseau et là tu as 2 adresses ip, je me dis que ça peut avoir un rapport.
J’ai déjà lu sur ce forum qu’il fallait éviter le filaire simultanément avec le wifi.
J’ai déconnecté les miens (tu as juste à commenter quelques lignes dans le wpa-supplicant puis reboot).
1 « J'aime »
Bonjour,
Ce matin pour moi tout est OK, mais en général le plantage c’est tout les deux jours ! ! !
Je suis ce post avec intérêt.
Salutations
Jean-Paul
1 « J'aime »
Moi, ça recommence. J’avais une session SSH ouverte
Message from syslogd@RPi4b-Jeedom at Nov 27 17:02:17 ...
kernel:[281868.159155] Internal error: Oops: 96000046 [#1] PREEMPT SMP
Message from syslogd@RPi4b-Jeedom at Nov 27 17:02:17 ...
kernel:[281868.159484] Code: d65f03c0 cb0803e4 f2400c84 54000080 (a9001d07)
Là, je n’en peux plus, j’ai juste envie de défoncer ce RPi4 à coup de pioche ! 
1 « J'aime »
Fais:
tail /var/log/messagesTu peux aussi regarder ton dmesg.
ps: pitié pour le pi
Pétard c’est fou ça 
Finalement je n’ai eu ce soucis que le 23 Novembre et depuis tout est parfait.
Tant mieux car c’est ingerable ce truc.
À voir ton log, c’est fou le coup du 17 récurent quand-même 
Malheureusement, j’ai déjà regardé tous les fichiers dans /var/log/, je ne trouve pas la cause qui fait rebooter le RPi.
On voit un reboot, mais le pi n’arrive pas à démarrer correctement : plus de SSH, Jeedom reste en vrac !
1 « J'aime »
pour le 17 recurrent, c’est le RPI qui loggue sa date toute les heures à 17 minute.
Lorsque le RPI reboote, vu qu’il n’a pas d’horloge, il repart de la date inscrite dans le fichier /etc/fake-hwclock.data plutôt que 1er janvier 1970
Vu que j’ai un SSD et pas une SDcard, j’ai mis « * * * * * /sbin/fake-hwclock save » dans le crontab de root pour avoir une mise à jour toute les minutes de mon fichier /etc/fake-hwclock.data
J’aime pas les logs qui reviennent trop dans le passé 
1 « J'aime »
Ouais, quand le RPi n’est pas connecté au réseau, je comprends.
J’ai activé l’option pour qu’il démarre le système après la connexion au réseau.
SSD ou pas, ça plante exactement de la même façon.
Jeedom n’aime pas aussi !
« J’ai activé l’option pour qu’il démarre le système après la connexion au réseau. »
Je vais pas comment l’OS ne peut démarrer que quand l’OS a du réseau.
Ma remarque sur la SDcard est pour limiter un peu les écritures sur la SD card (60x moins)
L’OS démarre de toute façon, mais doit éventuellement arrêter des étapes d’init s’il n’a pas le reseau.
Durant ce temps, il a 2 dates possibles 1/1/1970 (valeur timestamp 0) ou celle du fichier susmentionné lorsqu’il arrive à l’étape de récuperer la date dans le fichier. Après lorsque le reseau sera UP, il pourra se synchroniser avec le NTP et corriger sa date. Là ou dmesg est fort, c’est que la date n’est pas loggué, mais le temps en microsecondes depuis le demarrage (compteur OS). Du coup, si on change la date, l’information de date de démarrage est correcte rétroactivement.
Un essai? faire un simple reboot n’importe quand (mais pas à la date présente dans /etc/fake-hwclock.data). Regarder la date dans les logs systems qui logguent la date…
Un deuxieme: last | grep reboot
pi@raspberrypi:~ $ last | grep reboot
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 still running
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 08:41 (18634+07:41)
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 08:41 (18634+07:41)
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 09:53 (18628+08:53)
reboot system boot 5.4.79-v7l+ Thu Jan 1 01:00 - 09:53 (18628+08:53)
1 « J'aime »