Plantage total RPi4b - Serveur de temps NTP

Domatizer · Juin 15, 2020, 6:29

Bonjour,

Depuis que j’ai installé Jeedom sur un RPi4b+SSD il y un mois, le système plante complètement de temps en temps et plus rien ne répond. C’est aléatoire, le système peut tenir 2 jours comme une dizaine. Mais à un moment, c’est le black out. Un redémarrage et tout rentre dans l’ordre.

Après redémarrage dans l’onglet Santé, tout est au vert bien sûr.

Rien dans les log, je remarque juste qu’il a redémarré à l’heure où ça a planté à 21:17:06 et à l’heure où j’ai débranché/rebranché à 6:38:20

[Fri Jun 12 00:00:02.289415 2020] [mpm_prefork:notice] [pid 649] AH00171: Graceful restart requested, doing restart
[Fri Jun 12 00:00:02.644732 2020] [mpm_prefork:notice] [pid 649] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Fri Jun 12 00:00:02.644794 2020] [core:notice] [pid 649] AH00094: Command line: '/usr/sbin/apache2'
[Sat Jun 13 00:00:02.032819 2020] [mpm_prefork:notice] [pid 649] AH00171: Graceful restart requested, doing restart
[Sat Jun 13 00:00:02.376402 2020] [mpm_prefork:notice] [pid 649] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Sat Jun 13 00:00:02.376460 2020] [core:notice] [pid 649] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jun 14 00:00:02.755990 2020] [mpm_prefork:notice] [pid 649] AH00171: Graceful restart requested, doing restart
[Sun Jun 14 00:00:03.165362 2020] [mpm_prefork:notice] [pid 649] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Sun Jun 14 00:00:03.165418 2020] [core:notice] [pid 649] AH00094: Command line: '/usr/sbin/apache2'
[Sun Jun 14 21:17:06.815226 2020] [mpm_prefork:notice] [pid 635] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Sun Jun 14 21:17:06.815727 2020] [core:notice] [pid 635] AH00094: Command line: '/usr/sbin/apache2'
[Mon Jun 15 06:38:20.586168 2020] [mpm_prefork:notice] [pid 635] AH00171: Graceful restart requested, doing restart
[Mon Jun 15 06:38:21.058523 2020] [mpm_prefork:notice] [pid 635] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Mon Jun 15 06:38:21.058579 2020] [core:notice] [pid 635] AH00094: Command line: '/usr/sbin/apache2'

Remarque: Lorsqu’il plante, c’est toujours à la 17ième minute et 5 secondes de l’heure et il redémarre tout seul. Ici c’était 21:17:05

Jun 14 21:17:05 RPi4b-Jeedom fake-hwclock[108]: Sun 14 Jun 19:17:01 UTC 2020

Le RPi4 redémarre, mais Jeedom reste KO, injoinable et rien ne fonctionne.

Dans les log system, à la fin de son redémarrage lorsqu’il a redémarré tout seul, il est à l’étape de la synchronisation de l’heure

Jun 14 21:18:04 RPi4b-Jeedom systemd[1503]: Startup finished in 248ms.
Jun 14 21:18:04 RPi4b-Jeedom systemd[1]: Started User Manager for UID 1000.
Jun 14 21:18:04 RPi4b-Jeedom systemd[1]: Started Session c1 of user pi.
Jun 14 21:18:12 RPi4b-Jeedom ntpd[519]: Soliciting pool server 162.159.200.123
Jun 14 21:18:13 RPi4b-Jeedom ntpd[519]: Soliciting pool server 195.154.174.209
Jun 14 21:18:13 RPi4b-Jeedom ntpd[519]: Soliciting pool server 51.210.8.165
Jun 14 21:18:13 RPi4b-Jeedom ntpd[519]: Soliciting pool server 51.77.12.38
Jun 14 21:18:14 RPi4b-Jeedom ntpd[519]: Soliciting pool server 91.121.154.174
Jun 14 21:18:14 RPi4b-Jeedom ntpd[519]: Soliciting pool server 194.57.169.1
Jun 14 21:18:14 RPi4b-Jeedom ntpd[519]: Soliciting pool server 5.39.81.111
Jun 14 21:18:15 RPi4b-Jeedom ntpd[519]: Soliciting pool server 95.81.173.8
Jun 14 21:18:15 RPi4b-Jeedom ntpd[519]: Soliciting pool server 151.80.211.8
Jun 14 21:18:15 RPi4b-Jeedom ntpd[519]: Soliciting pool server 162.159.200.1
Jun 14 21:18:15 RPi4b-Jeedom ntpd[519]: Soliciting pool server 91.121.68.116
Jun 14 21:18:16 RPi4b-Jeedom ntpd[519]: Soliciting pool server 37.187.104.44
Jun 14 21:18:16 RPi4b-Jeedom ntpd[519]: Soliciting pool server 5.196.160.139
Jun 14 21:18:17 RPi4b-Jeedom ntpd[519]: Soliciting pool server 213.251.53.11
Jun 14 21:18:17 RPi4b-Jeedom ntpd[519]: Soliciting pool server 37.59.63.125
Jun 14 21:18:17 RPi4b-Jeedom ntpd[519]: Soliciting pool server 51.15.203.2
Jun 14 21:18:17 RPi4b-Jeedom ntpd[519]: Soliciting pool server 51.15.195.76

Ensuite, lorsque je coupe l’alim pour tout redémarrer le lendemain, je constate un problème avec le serveur de temps, mais Jeedom repart comme si de rien n’était.

Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f45105f3 does not match aorg 0000000000.00000000 from server@162.159.200.1 xmt 0xe29179bb.aa9d152d
Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f4475631 does not match aorg 0000000000.00000000 from server@51.15.195.76 xmt 0xe29179bb.aacb018a
Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f44f8254 does not match aorg 0000000000.00000000 from server@151.80.211.8 xmt 0xe29179bb.ab2f0135
Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f44c30b7 does not match aorg 0000000000.00000000 from server@5.196.160.139 xmt 0xe29179bb.ab7ebb9e
Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f4541e53 does not match aorg 0000000000.00000000 from server@51.77.12.38 xmt 0xe29179bb.ab8ce3da
Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f44dec00 does not match aorg 0000000000.00000000 from server@95.81.173.8 xmt 0xe29179bb.aa3777d3
Jun 15 06:38:19 RPi4b-Jeedom ntpd[519]: receive: Unexpected origin timestamp 0xe290f67c.f4529246 does not match aorg 0000000000.00000000 from server@194.57.169.1 xmt 0xe29179bb.aba6df9a
Jun 15 06:38:19 RPi4b-Jeedom systemd[1]: Starting Rotate log files...
Jun 15 06:38:19 RPi4b-Jeedom systemd[1]: Starting Daily man-db regeneration...
Jun 15 06:38:19 RPi4b-Jeedom systemd[1]: Starting Daily apt download activities...
Jun 15 06:38:19 RPi4b-Jeedom systemd[1]: Starting Clean php session files...
Jun 15 06:38:20 RPi4b-Jeedom systemd[1]: Reloading The Apache HTTP Server.
Jun 15 06:38:20 RPi4b-Jeedom systemd[1]: phpsessionclean.service: Succeeded.
Jun 15 06:38:20 RPi4b-Jeedom systemd[1]: Started Clean php session files.
Jun 15 06:38:20 RPi4b-Jeedom systemd[1]: Reloaded The Apache HTTP Server.

Dons Jeedom, j’ai configuré le serveur de temps comme ceci

Avant le premier plantage, je n’avais pas de serveur de temps dans Jeedom.

De plus, auparavant, je n’ai jamais eu ce genre de souci avec le Raspberry Pi 3 ou un EecPC et je ne réglais jamais rien à ce sujet.

La commande timedatectl retourne bien la bonne heure (il est 7h54m49)

               Local time: Mon 2020-06-15 07:54:49 CEST
           Universal time: Mon 2020-06-15 05:54:49 UTC
                 RTC time: n/a
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

Ici, on voit que le service NTP n’est pas actif

Or la commande service ntp status retourne

● ntp.service - Network Time Service
   Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2020-06-15 07:01:26 CEST; 56min ago
     Docs: man:ntpd(8)
  Process: 31678 ExecStart=/usr/lib/ntp/ntp-systemd-wrapper (code=exited, status=0/SUCCESS)
 Main PID: 31684 (ntpd)
    Tasks: 2 (limit: 4915)
   Memory: 1008.0K
   CGroup: /system.slice/ntp.service
           └─31684 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 109:114

Jun 15 07:01:31 RPi4b-Jeedom ntpd[31684]: Soliciting pool server 151.80.44.158
Jun 15 07:01:32 RPi4b-Jeedom ntpd[31684]: Soliciting pool server 151.80.32.71
Jun 15 07:01:33 RPi4b-Jeedom ntpd[31684]: Soliciting pool server 2001:718:1e03:801::2
Jun 15 07:11:36 RPi4b-Jeedom ntpd[31684]: 194.57.169.1 local addr 192.168.1.64 -> <null>
Jun 15 07:11:39 RPi4b-Jeedom ntpd[31684]: 95.81.173.8 local addr 192.168.1.64 -> <null>
Jun 15 07:15:05 RPi4b-Jeedom ntpd[31684]: 129.250.35.250 local addr 192.168.1.64 -> <null>
Jun 15 07:27:12 RPi4b-Jeedom ntpd[31684]: 151.80.32.71 local addr 192.168.1.64 -> <null>
Jun 15 07:27:15 RPi4b-Jeedom ntpd[31684]: 212.83.145.32 local addr 192.168.1.64 -> <null>
Jun 15 07:27:22 RPi4b-Jeedom ntpd[31684]: 37.59.63.125 local addr 192.168.1.64 -> <null>
Jun 15 07:36:11 RPi4b-Jeedom ntpd[31684]: 163.172.87.139 local addr 192.168.1.64 -> <null>

Après des lectures sur le sujet, j’apprends qu’il n’y a pas d’horloge RTC intégré dans le RPi. Arrf

Je précise que le RPi est branché sur onduleur (pour éviter tous le soucis d’alim, hein !) et relié à la box internet (et je n’ai pas reçu d’alerte de coupure internet).

Que faut-il faire pour avoir ne pas avoir de problème d’horloge avec le RPi4 ?

naboleo · Juin 15, 2020, 6:37

Salut,

Je note avec intérêt ton message. J’ai également eu 2 plantages sans explication, je vais creuser cette piste.
Constat similaire donc : ntp inactif mais service OK… Petite différence tout de même 3 lignes étranges :

juin 11 07:57:23 raspberrypi ntpd[571]: receive: Unexpected origin timestamp 0xe28c20fe.b708cc37 does not match aorg 0000000000.00000000 from server@92.243.6.5 xmt 0x
juin 11 07:57:23 raspberrypi ntpd[571]: receive: Unexpected origin timestamp 0xe28c20fe.b707b9c8 does not match aorg 0000000000.00000000 from server@51.254.208.135 xm
juin 11 07:57:23 raspberrypi ntpd[571]: receive: Unexpected origin timestamp 0xe28c20fe.b7028357 does not match aorg 0000000000.00000000 from server@178.249.167.0 xmt
juin 11 08:06:21 raspberrypi ntpd[571]: 80.74.64.2 local addr 192.168.1.49 -> <null>
juin 11 08:07:22 raspberrypi ntpd[571]: 178.249.167.0 local addr 192.168.1.49 -> <null>
juin 11 08:45:00 raspberrypi ntpd[571]: 129.250.35.251 local addr 192.168.1.49 -> <null>
juin 11 08:45:09 raspberrypi ntpd[571]: 37.187.104.44 local addr 192.168.1.49 -> <null>
juin 11 08:45:09 raspberrypi ntpd[571]: 212.83.179.156 local addr 192.168.1.49 -> <null>
juin 11 08:45:13 raspberrypi ntpd[571]: 193.252.223.86 local addr 192.168.1.49 -> <null>
juin 11 08:49:18 raspberrypi ntpd[571]: 51.159.6.183 local addr 192.168.1.49 -> <null>

Après redemarrage du service manuellement : la synchro est off

root@raspberrypi:~# timedatectl
               Local time: lun. 2020-06-15 08:35:29 CEST
           Universal time: lun. 2020-06-15 06:35:29 UTC
                 RTC time: n/a
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

et des erreurs relatives au kernel

juin 15 08:35:24 raspberrypi ntpd[16995]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized
juin 15 08:35:24 raspberrypi ntpd[16995]: kernel reports TIME_ERROR: 0x2041: Clock Unsynchronized

A suivre et à creuser mais ça sent le bug de la distrib (ici version 64 bits)

Domatizer · Juin 15, 2020, 6:59

Au début, je pensais un problème USB, d’alimentation ou de SSD.
Mais non, ça plante toujours à la 17ième minute ! Et avec un redémarrage raté !

C’est 32bits avec Raspbian
Dashboard - Jeedom
Bon, au point où j’en suis, j’ai fait des mises à jour de Raspbian… À surveiller…

naboleo · Juin 15, 2020, 7:02

Bon là on est bien différents :

Pour info, la version 64b est dispo depuis quelques semaines
https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=275370

EDIT :
petite màj de mon coté

root@raspberrypi:~# sudo apt install htpdate
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
Les NOUVEAUX paquets suivants seront installés :
  htpdate
0 mis à jour, 1 nouvellement installés, 0 à enlever et 0 non mis à jour.
Il est nécessaire de prendre 18,2 ko dans les archives.
Après cette opération, 60,4 ko d'espace disque supplémentaires seront utilisés.
Réception de :1 http://deb.debian.org/debian buster/main arm64 htpdate arm64 1.2.0-3 [18,2 kB]
18,2 ko réceptionnés en 0s (222 ko/s)
Sélection du paquet htpdate précédemment désélectionné.
(Lecture de la base de données... 115100 fichiers et répertoires déjà installés.)
Préparation du dépaquetage de .../htpdate_1.2.0-3_arm64.deb ...
Dépaquetage de htpdate (1.2.0-3) ...
Paramétrage de htpdate (1.2.0-3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/htpdate.service → /lib/systemd/system/htpdate.service.
Traitement des actions différées (« triggers ») pour man-db (2.8.5-2) ...
Traitement des actions différées (« triggers ») pour systemd (241-7~deb10u4) ...

Domatizer · Juin 15, 2020, 7:25

La bonne nouvelle, c’est qu’on a le même souci sur 2 architectures différentes.

Perso, il y déjà assez de problèmes en tout genre, donc j’évite les versions beta, les mises à jour lorsque tout fonctionne.

Domatizer · Juin 16, 2020, 10:29

Ça recommence !!!
Le système redémarre tout seul encore à la 17ième minute et 5 secondes et reste en vrac !!!

Dans le fichier /var/log/daemon.log, il ne trouve pas les sites *.debian.pool.ntp.org

Jun 16 09:17:05 RPi4b-Jeedom fake-hwclock[114]: Tue 16 Jun 07:17:01 UTC 2020
Jun 16 09:17:05 RPi4b-Jeedom ntpd[503]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jun 16 09:17:05 RPi4b-Jeedom ntpd[503]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized
Jun 16 09:17:06 RPi4b-Jeedom ntpd[503]: error resolving pool 0.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 16 09:17:07 RPi4b-Jeedom ntpd[503]: error resolving pool 1.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 16 09:17:08 RPi4b-Jeedom ntpd[503]: error resolving pool 2.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 16 09:17:09 RPi4b-Jeedom ntpd[503]: error resolving pool 3.debian.pool.ntp.org: Temporary failure in name resolution (-3)
Jun 16 09:18:12 RPi4b-Jeedom ntpd[503]: Soliciting pool server 80.74.64.2
Jun 16 09:18:12 RPi4b-Jeedom ntpd[503]: Soliciting pool server 131.211.8.244
Jun 16 09:18:13 RPi4b-Jeedom ntpd[503]: Soliciting pool server 91.121.144.16
Jun 16 09:18:13 RPi4b-Jeedom ntpd[503]: Soliciting pool server 78.129.163.63
Jun 16 09:18:14 RPi4b-Jeedom ntpd[503]: Soliciting pool server 51.159.6.183
Jun 16 09:18:14 RPi4b-Jeedom ntpd[503]: Soliciting pool server 91.236.251.62
Jun 16 09:18:14 RPi4b-Jeedom ntpd[503]: Soliciting pool server 212.85.158.10
Jun 16 09:18:15 RPi4b-Jeedom ntpd[503]: Soliciting pool server 195.154.174.209
Jun 16 09:18:15 RPi4b-Jeedom ntpd[503]: Soliciting pool server 151.80.211.8
Jun 16 09:18:15 RPi4b-Jeedom ntpd[503]: Soliciting pool server 193.107.56.65
Jun 16 09:18:15 RPi4b-Jeedom ntpd[503]: Soliciting pool server 129.250.35.251
Jun 16 09:18:16 RPi4b-Jeedom ntpd[503]: Soliciting pool server 82.64.84.116
Jun 16 09:18:16 RPi4b-Jeedom ntpd[503]: Soliciting pool server 162.159.200.1
Jun 16 09:18:17 RPi4b-Jeedom ntpd[503]: Soliciting pool server 51.15.191.239
Jun 16 09:18:17 RPi4b-Jeedom ntpd[503]: Soliciting pool server 178.249.167.0
Jun 16 09:18:18 RPi4b-Jeedom ntpd[503]: Soliciting pool server 212.83.187.62
Jun 16 09:18:19 RPi4b-Jeedom ntpd[503]: Soliciting pool server 2001:41d0:305:2100::621

Puis après rebranchement de l’alim, le système refonctionne normalement avec comme toi @naboleo les problèmes de timestamp

Jun 16 11:35:58 RPi4b-Jeedom ntpd[503]: receive: Unexpected origin timestamp 0xe292f0bb.8e7bf82f does not match aorg 0000000000.00000000 from server@80.74.64.2 xmt 0xe29310fe.4d7278bd
Jun 16 11:35:58 RPi4b-Jeedom ntpd[503]: receive: Unexpected origin timestamp 0xe292f0bb.8e75251b does not match aorg 0000000000.00000000 from server@212.85.158.10 xmt 0xe29310fe.4e1d0a04
Jun 16 11:35:58 RPi4b-Jeedom systemd[1]: Starting Clean php session files...
Jun 16 11:35:58 RPi4b-Jeedom ntpd[503]: receive: Unexpected origin timestamp 0xe292f0bb.8e767eb4 does not match aorg 0000000000.00000000 from server@91.236.251.62 xmt 0xe29310fe.5336c676
Jun 16 11:35:58 RPi4b-Jeedom systemd[1]: phpsessionclean.service: Succeeded.
Jun 16 11:35:58 RPi4b-Jeedom systemd[1]: Started Clean php session files.

Dans le fichier /var/log/syslog, on dirait que les interfaces réseau Ethernet et Wi-Fi ne sont pas opérationnelles

Jun 16 09:17:12 RPi4b-Jeedom ntpd[503]: bind(23) AF_INET6 fe80::3295:91d5:8a16:e0a9%2#123 flags 0x11 failed: Cannot assign requested address
Jun 16 09:17:12 RPi4b-Jeedom ntpd[503]: unable to create socket on eth0 (4) for fe80::3295:91d5:8a16:e0a9%2#123
Jun 16 09:17:12 RPi4b-Jeedom ntpd[503]: failed to init interface for address fe80::3295:91d5:8a16:e0a9%2
Jun 16 09:17:12 RPi4b-Jeedom ntpd[503]: bind(23) AF_INET6 fe80::d1b1:a9be:1d2d:39a4%3#123 flags 0x11 failed: Cannot assign requested address
Jun 16 09:17:12 RPi4b-Jeedom ntpd[503]: unable to create socket on wlan0 (5) for fe80::d1b1:a9be:1d2d:39a4%3#123
Jun 16 09:17:12 RPi4b-Jeedom ntpd[503]: failed to init interface for address fe80::d1b1:a9be:1d2d:39a4%3
Jun 16 09:17:14 RPi4b-Jeedom ntpd[503]: Listen normally on 6 eth0 [fe80::3295:91d5:8a16:e0a9%2]:123
Jun 16 09:17:14 RPi4b-Jeedom ntpd[503]: Listen normally on 7 wlan0 [fe80::d1b1:a9be:1d2d:39a4%3]:123
Jun 16 09:17:14 RPi4b-Jeedom ntpd[503]: new interface(s) found: waking up resolver

De plus, j’avais une session SSH ouverte à cet instant.
Que des messages à faire peur ! (je n’affiche que les premières lignes)

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299581] Internal error: Oops: 205 [#1] SMP ARM

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299809] Process owserver (pid: 13727, stack limit = 0x2574dbb6)

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299818] Stack: (0xd389bc10 to 0xd389c000)

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299827] bc00:                                     00000020 00000002 c0305a7c 013b3a7b

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299839] bc20: 20000013 c07a0a60 d389bc54 00000001 efaf3000 006000c0 00000002 db480000

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299851] bc40: da83ef00 efaf3014 d389bca4 d389bc58 c07a67b8 c03beb34 00000001 c0a4d800

Message from syslogd@RPi4b-Jeedom at Jun 16 09:31:09 ...
 kernel:[96854.299863] bc60: c0683088 c0685110 d389bca4 00000005 efaf3150 dbc40600 00000002 da83ef00

Le RPi4 est à jour : raspi-config is already the newest version (20200601).

Auriez-vous des idées pour avancer dans le debug ? Il est déjà mort ce RPi4 ?

naboleo · Juin 16, 2020, 10:38

Salut,

ça c’est je pense la conséquence directe d’une mauvaise synchro de l’heure… Si tu es en DHCP, pour négocier l’adresse ip, l’heure est importante dans l’établissement/renouvellement du bail… ça vaut peut-être le coup d tenter de mettre l’ip en fixe

A noter que j’ai pas eu de souci ce matin de mon coté, je touche de la peau de singe
Difficile voir si la 17ième minute est importante aussi chez moi mais il y a ça dans la cron tab… quel truc de « runparts » est en cause, je sais pas encore

# /etc/crontab: system-wide crontab
# Unlike any other crontab you don't have to run the `crontab'
# command to install the new version when you edit this file
# and files in /etc/cron.d. These files also have username fields,
# that none of the other crontabs do.

SHELL=/bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin

# Example of job definition:
# .---------------- minute (0 - 59)
# |  .------------- hour (0 - 23)
# |  |  .---------- day of month (1 - 31)
# |  |  |  .------- month (1 - 12) OR jan,feb,mar,apr ...
# |  |  |  |  .---- day of week (0 - 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
# |  |  |  |  |
# *  *  *  *  * user-name command to be executed
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.daily )
47 6    * * 7   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )
52 6    1 * *   root    test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.monthly )

Le cron hourly est vide …

root@raspberrypi:~# more /etc/cron.hourly

*** /etc/cron.hourly: directory ***

root@raspberrypi:~#

Domatizer · Juin 16, 2020, 11:02

Oui, c’est bien un problème de mauvaise synchronisation de l’heure mais pourquoi ?
Jamais eu de souci de ce genre avec le RPi3b

L’IP est déjà fixe pour l’Ethernet. De plus, si je débranche le câble, le Wi-Fi prend le relai.
Pas de souci sur la base internet non plus.

Bien vu le /etc/crontab, il se passe des choses à la 17ième minute

17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly

Chez moi, il n’est pas vide : /etc/cron.hourly contient un script fake-hwclock

#!/bin/sh
#
# Simple cron script - save the current clock periodically in case of
# a power failure or other crash

if (command -v fake-hwclock >/dev/null 2>&1) ; then
  fake-hwclock save
fi

Donc toutes les heures, il vérifie la synchro de l’heure : OK
Mais pourquoi il système se permet de redémarrer le RPi !

naboleo · Juin 16, 2020, 11:07

Bon ben ça correspond à ton erreur

Jun 16 09:17:05 RPi4b-Jeedom fake-hwclock[114]: Tue 16 Jun 07:17:01 UTC 2020
Jun 16 09:17:05 RPi4b-Jeedom ntpd[503]: kernel reports TIME_ERROR: 0x41: Clock Unsynchronized

Donc tu peux sans doute suspendre cette tache pour l’instant, sans coupure de courant, tu devrais pouvoir garder l’heure a peu pret à jour.

Tu es certain qu’il y a un reboot ? Pour le reste des réponses, si je les avaient…

Par ailleurs, tu aurais pas migré depuis jessie par hasard (et donc gardé cette tache lors de la migration) ?

https://www.raspberrypi.org/forums/viewtopic.php?t=200385

Domatizer · Juin 16, 2020, 11:23

Oui c’est bien le fake-hwclock.

J’ai regardé mes autres RPi3b, ils ont aussi ce script fake-hwclock qui tourne et ils n’ont pas de souci.

Oui, en plus, j’ai l’onduleur

Oui, il reboot complètement mais mal, on le voit dans les log système

Non, installe clean à chaque fois.

Mouais. Que de bidouilles !

J’avais justement choisi le RPi4 pour sa compatibilité afin de ne pas être le seul à avoir un problème particulier.

naboleo · Juin 16, 2020, 11:33

Rhooo, rentrer dans la norme c’est pas drôle ! Celà dit, on est au moins 2 à avoir un souci et pas forcement le même en plus

Domatizer · Juin 16, 2020, 11:53

Cela fait des mois que j’essaie d’avoir un système domotique « fiable ».
Donc, tous les problèmes de ce genre m’amusent de moins en moins !

Domatizer · Juin 17, 2020, 4:50

Jute pour compléter les log

Dans le log http.error de Jeedom, on voit qu’il redémarre bien à 9h18 et ensuite, il s’emmêle les pinceaux avec les time stamps

2020-06-16 09:18:02 starting Jeedom	tar: 00/5b636d64436163686541747472313830335d5b315d.doctrinecache.data: time stamp 2020-06-16 09:29:15 is 670.789042481 s in the future
tar: 00: time stamp 2020-06-16 09:29:15 is 670.788403086 s in the future
tar: 01/5b636d64436163686541747472313332305d5b315d.doctrinecache.data: time stamp 2020-06-16 09:30:04 is 719.788271552 s in the future
tar: 01/5b636d6443616368654174747238305d5b315d.doctrinecache.data: time stamp 2020-06-16 09:29:51 is 706.788190961 s in the future
tar: 01/5b636d64436163686541747472313833315d5b315d.doctrinecache.data: time stamp 2020-06-16 09:29:17 is 672.788112944 s in the future
tar: 01/5b636d64436163686541747472323730385d5b315d.doctrinecache.data: time stamp 2020-06-16 09:28:38 is 633.78803539 s in the future
tar: 01/5b636d644361636865417474723533385d5b315d.doctrinecache.data: time stamp 2020-06-16 09:28:38 is 633.787958077 s in the future
tar: 01/5b636d644361636865417474723536315d5b315d.doctrinecache.data: time stamp 2020-06-16 09:28:34 is 629.787850394 s in the future

Remarque : je n’ai pas ce type d’erreur à chaque plantage, c’est la 2ième fois.

Dans les options boot de raspi-config, j’ai sélectionné « attendre la connexion réseau au démarrage »

naboleo · Juin 17, 2020, 10:37

A priori c’est courant quand même…

https://forum.jeedom.com/viewtopic.php?t=42058

Domatizer · Juillet 27, 2020, 7:29

Ça recommence… toujours à la 17ième minute Jul 25 01:17:04
Le système a tenu 1 mois cette fois ci. Je n’avais pas fait de MAJ du système depuis la dernière

**Ça bug, le RPi redémarre (voir les log, il y a tout le cycle du redémarrage)
Jeedom se lance (j’ai reçu le mail d’alerte à 1h18)
Pourquoi le RPi et Jeedom ne redémarrent pas correctement ?
Jeedom se retrouve en vrac, instance inaccessible, la partie GSM ne fonctionne pas, les modules Z-Wave non plus, le réseau n’a pa pu redémarrer.
Je coupe puis je remets l’alim du RPi et tout rentre l’ordre, mais ça me gonfle.

Je mets les fichiers log
kern.log.txt (42,2 Ko)
user.log.txt (3,7 Ko)
debug.txt (10,0 Ko)
syslog.txt (109,9 Ko)
messages.txt (51,1 Ko)

Ça plante à Jul 25 01:17:04 Je ne sais pas ce qui ne va pas avec cette horloge. Dans le log, je vois qu’il y a un décalage de 5 minute. On passe de 01:22:02 à 01:17:04 Certains fichier log sont corrompu juste avant

Jul 25 01:15:01 RPi4b-Jeedom CRON[20154]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:16:01 RPi4b-Jeedom CRON[21526]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:17:01 RPi4b-Jeedom CRON[22705]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:17:01 RPi4b-Jeedom CRON[22706]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 25 01:18:01 RPi4b-Jeedom CRON[23896]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:18:57 RPi4b-Jeedom systemd[1]: Starting Certbot...
Jul 25 01:19:01 RPi4b-Jeedom CRON[25068]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:20:01 RPi4b-Jeedom CRON[26276]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:20:01 RPi4b-Jeedom CRON[26277]: (root) CMD (/usr/bin/php /var/www/html/core/php/watchdog.php >> /dev/null)
Jul 25 01:20:07 RPi4b-Jeedom certbot[25004]: Attempting to renew cert (matthieuleboulaire.ddns.net) from /etc/letsencrypt/renewal/matthieuleboulaire.ddns.net.conf produced an unexpected error: Failed authorization procedure. matthieuleboulaire.ddns.net (http-01): urn:ietf:params:acme:error:connection :: The server could not connect to the client to verify the domain :: Fetching http://matthieuleboulaire.ddns.net/.well-known/acme-challenge/-fNLFhni7AwYqFX6eCSwaiFHny7pNtbj2UNqq0TIoEE: Timeout during connect (likely firewall problem). Skipping.
Jul 25 01:20:07 RPi4b-Jeedom certbot[25004]: All renewal attempts failed. The following certs could not be renewed:
Jul 25 01:20:07 RPi4b-Jeedom certbot[25004]:   /etc/letsencrypt/live/matthieuleboulaire.ddns.net/fullchain.pem (failure)
Jul 25 01:20:07 RPi4b-Jeedom certbot[25004]: 1 renew failure(s), 0 parse failure(s)
Jul 25 01:20:08 RPi4b-Jeedom systemd[1]: certbot.service: Main process exited, code=exited, status=1/FAILURE
Jul 25 01:20:08 RPi4b-Jeedom systemd[1]: certbot.service: Failed with result 'exit-code'.
Jul 25 01:20:08 RPi4b-Jeedom systemd[1]: Failed to start Certbot.
Jul 25 01:21:01 RPi4b-Jeedom CRON[27638]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Jul 25 01:22:02 RPi4b-Jeedom CRON[28829]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00Jul 25 01:17:04 RPi4b-Jeedom fake-hwclock[124]: Fri 24 Jul 23:17:01 UTC 2020
Jul 25 01:17:04 RPi4b-Jeedom systemd-fsck[133]: e2fsck 1.44.5 (15-Dec-2018)
Jul 25 01:17:04 RPi4b-Jeedom systemd-fsck[133]: rootfs: clean, 109979/7646464 files, 2159408/31192064 blocks
Jul 25 01:17:04 RPi4b-Jeedom systemd[1]: Started udev Coldplug all Devices.
Jul 25 01:17:04 RPi4b-Jeedom systemd[1]: Starting Helper to synchronize boot up for ifupdown...

J’ai bien compris que le RPi n’avait pas d’horloge, mais il a toujours accès à internet et j’ai activé l’option « attendre le réseau avant de démarrer » pour être sûr qu’il obtienne la bonne heure avant de commencer. Comme peut-on avoir plusieurs minutes de décalage sachant qu’il se synchronise régulièrement avec internet ? On est loin d’avoir un truc autonome avec ce Pi.

naboleo · Juillet 27, 2020, 9:47

Il y a tout un tas de trucs qui se lancent autour de cet horaire chez toi. Plusieurs cron dans jeedom, la vérification certbot… Bref essaye de faire la liste et de repartir ça sur une plus longue période…
Que les fichiers soient corrompus c’est juste la conséquence du changement d’heure en plein milieu de leur utilisation…
Il y a aussi un cron jeedom toutes les minutes à vérifier

Domatizer · Juillet 27, 2020, 11:33

Qu’il y ait bug et qu’il redémarre : OK
Mais que Jeedom n’arrive pas à redémarrer correctement, ce n’est vraiment pas cool.
Les daemons de certains plugins démarrent bien, d’autres non

Dans le log du http.error, on remonte dans le temps.

[Sat Jul 25 01:19:50.928893 2020] [mpm_prefork:notice] [pid 651] AH00171: Graceful restart requested, doing restart
[Sat Jul 25 01:19:51.095838 2020] [mpm_prefork:notice] [pid 651] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Sat Jul 25 01:19:51.095882 2020] [core:notice] [pid 651] AH00094: Command line: '/usr/sbin/apache2'
[Sat Jul 25 01:20:07.619671 2020] [mpm_prefork:notice] [pid 651] AH00171: Graceful restart requested, doing restart
[Sat Jul 25 01:20:07.767821 2020] [mpm_prefork:notice] [pid 651] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Sat Jul 25 01:20:07.767864 2020] [core:notice] [pid 651] AH00094: Command line: '/usr/sbin/apache2'
[Sat Jul 25 01:17:06.415592 2020] [mpm_prefork:notice] [pid 575] AH00163: Apache/2.4.38 (Raspbian) OpenSSL/1.1.1d configured -- resuming normal operations
[Sat Jul 25 01:17:06.415984 2020] [core:notice] [pid 575] AH00094: Command line: '/usr/sbin/apache2'

Je pense qu’une dérive temporelle de 3 minutes sur un mois est possible et j’ai l’impression que l’horloge du Pi n’est pas synchronisée. Elle est simplement vérifiée toutes les heures. Puis lorsque la dérive temporelle est trop importante, ce qui fini tôt ou tard par arriver, le Pi fait un reset. Là, il y a une resynchronisation brutale de l’heure au redémarrage. Jeedom bloque car sa base de données est remontée dans le temps. D’ailleurs, lors du prochain redémarrage, qui a lieu généralement assez longtemps plus tard, tout se passe bien.

naboleo · Juillet 27, 2020, 12:04

Possible, sauf que c’est pas un comportement classique. J’ai rarement eu ce genre d’erreur et de décalage temporel.
Comme c’est assez peu probable que ce soit un souci hardware, il faut chercher du côté des applications et de la configuration matérielle

Domatizer · Juillet 27, 2020, 12:42

Oui, je pense que c’est du soft et qu’il n’y a pas de synchro
La commande timedatectl retourne

               Local time: Mon 2020-07-27 14:27:13 CEST
           Universal time: Mon 2020-07-27 12:27:13 UTC
                 RTC time: n/a
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: inactive
          RTC in local TZ: no

Le service NTP n’est pas actif chez moi !

J’ai viré le service NTP et utilisé le service systemd-timesyncd à la place

Maintenant, la commande timedatectl retourne

               Local time: Mon 2020-07-27 15:24:48 CEST
           Universal time: Mon 2020-07-27 13:24:48 UTC
                 RTC time: n/a
                Time zone: Europe/Paris (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Pour info, je me suis inspiré de ceci

Mon fichier /etc/systemd/timesyncd.conf contient

[Time]
#NTP
#NTP=ntp.serveur1.fr ntp.serveur2.fr
#FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
FallbackNTP=0.debian.pool.ntp.org 1.debian.pool.ntp.org 2.debian.pool.ntp.org 3.debian.pool.ntp.org
#RootDistanceMaxSec=5
#PollIntervalMinSec=32
#PollIntervalMaxSec=2048

Enfin, la commande sudo service systemd-timesyncd status montre


● systemd-timesyncd.service - Network Time Synchronization
   Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled)
  Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
           └─disable-with-time-daemon.conf
   Active: active (running) since Mon 2020-07-27 15:24:15 CEST; 2min 52s ago
     Docs: man:systemd-timesyncd.service(8)
 Main PID: 11074 (systemd-timesyn)
   Status: "Synchronized to time server for the first time 213.136.0.252:123 (0.debian.pool.ntp.org)."
    Tasks: 2 (limit: 4915)
   CGroup: /system.slice/systemd-timesyncd.service
           └─11074 /lib/systemd/systemd-timesyncd

Jul 27 15:24:15 RPi4b-Jeedom systemd[1]: Starting Network Time Synchronization...
Jul 27 15:24:15 RPi4b-Jeedom systemd[1]: Started Network Time Synchronization.
Jul 27 15:24:15 RPi4b-Jeedom systemd-timesyncd[11074]: Synchronized to time server for the first time 213.136.0.252:123 (0.debian.pool.ntp.org).

À voir si ça tient dans le temps cette fois

naboleo · Août 7, 2020, 6:51

Je suis tombé la dessus par hasard

/var/www/html/core/php/watchdog.php


/********************************Date****************************************/
echo 'Check Date => ';
echo date('Y-m-d')."\n";
if(date('Y') < 2019 || date('Y') > 2040){
	echo 'Invalid date found, try correct it';
	exec('sudo service ntp stop;sudo ntpdate -s time.nist.gov;sudo service ntp start');
}

/********************************Free space****************************************/

et jeedom.class.php

	public static function forceSyncHour() {
		if(config::byKey('disable_ntp','core',0) == 1){
			return;
		}
		shell_exec(system::getCmdSudo() . 'service ntp stop;' . system::getCmdSudo() . 'ntpdate -s ' . config::byKey('ntp::optionalServer', 'core', '0.debian.pool.ntp.org') . ';' . system::getCmdSudo() . 'service ntp start');
	}

ça fait pas avancer le truc, mais ça montre quand même qu’il ya potentiellement des actions que l’on ne soupçonne pas