403 Forbidden - You don't have permission to access this resource

Bonjour à tous,

Je rencontre aléatoirement l’erreur suivante sur mon installation Jeedom :

Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

Mon setup est le suivant :

  • Raspberry pi 3B+ alimenté seul via une alimentation 3A, et branché en RJ45
  • Hub USB auto-alimenté avec clé Zwave
  • SSD avec boitier auto-alimenté
  • OS : Raspbian GNU/Linux 9 (stretch)
  • Jeedom : 4.0.61

Quand j’ai l’erreur, le RPI est pingable, mais impossible de se connecter via ssh… Seul moyen : hard reboot…

A l’origine le RPI alimentait le SSD et la clé Zwave, je pensais résoudre cette erreur en ayant une alimentation dédiée à chacun des éléments, mais malheureusement, ce n’est pas le cas…
L’erreur apparait de manière totalement aléatoire, à n’importe quelle heure, des fois en pleine nuit, des fois en pleine journée…
Elle peut survenir quelques minutes après un reboot, ou après quelques heures… Le setup a même déjà tenu plusieurs mois !!
Je viens de l’avoir 2 fois en 45 minutes, alors que je ne l’avais pas eue depuis Samedi soir…

Je commence à désespérer, et j’ai épuisé toutes les pistes que j’avais identifiées… Je fais appel à la communauté en espérant avoir un regard nouveau sur ce problème afin de trouver une solution stable…

Merci !!

Bonsoir.

Vous avez ce message ou ?

Idée : refaire une installation de Raspberry pi Os en version Buster (10).
Installez Jeedom.
Restaurez votre sauvegarde.

Testez ainsi.

En cas de problème dans ces conditions, il faut au moins avoir la liste de vos plugins.

1 « J'aime »

Buster ? C’est un risque de voir un ou plusieurs plugin tiers ne plus fonctionner non…?

1 « J'aime »

Ba non, sinon je ne conseillerais pas :thinking:.

Je pense que 100% des connaisseurs sont déjà sur Buster.

Édit : je dirais même que si c’était le cas, il faut fuire ces plugins, car cela signifie qu’ils ne sont plus maintenues.

3 « J'aime »

Merci pour vos réponses !
@Fabrice je risque de passer pour un casse-couilles, mais ré-installer entièrement le système n’est définitivement pas la bonne solution… Cela ne permettra jamais d’identifier la root cause et cela ne garantit en rien que le problème ne se reproduira pas (car pas identifié)…
C’est pour moi la solution « de la dernière chance ». Mais je reste convaincu qu’il y a d’autres leviers avant.

Hier soir je me suis inspiré de la migration Ngnix → Apache sur la doc officielle. J’ai donc joué les deux commandes suivantes :

chmod 775 -R /var/www/html
chown www-data:www-data -R /var/www/html

Puis

systemctl daemon-reload
systemctl restart apache2.service

Je n’ai depuis pas eu le souci, mais comme il arrive aléatoirement, je ne sais pas s’il est corrigé… Je vais laisser tourner comme ça plusieurs jours, en croisant les doigts…

En réfléchissant bien, je ne pense pas que le souci vienne de Jeedom. J’ai en tête quatre possibilités :

  • Le raspberry : Problème hardware ? ==> Que puis-je faire de mon côté pour vérifier que tout fonctionne correctement ?
  • L’alimentation : Celle du SSD je suppose, vu que celle du raspberry est une 3A et que le RPI n’alimente rien via ses ports USB ==> Je vais essayer d’alimenter le SSD avec une autre alimentation.
  • Le SSD : mais cela m’étonnerait fortement, car il n’a qu’un an et n’a été utilisé que par le RPI…
  • Problème électrique : des micro-coupures chez moi ? Auxquelles que SSD serait intolérant, ce qui empêcherait le RPI d’y accéder ? ==> Comment puis-je vérifier une telle chose ?

Encore merci pour vos réponses :slight_smile:

Bonjour,

Je pense que vous faites une erreur d’appréciation sur le faite de réaliser une installation, de zéro, sur le pi.

En voici les avantages :

  • Temps de réalisation : 30 minutes / 1 heure
  • Vous serez nativement sur Buster
  • Bonne version de PHP / Apache / MariaDB

Après, si vous avez encore cette erreur, vous avez l’avantage de savoir que cela ne vient pas de votre installation OS :wink:

Pour les problèmes d’OS, vous avez les logs dans /var/log

1 « J'aime »

Bonjour,
est-ce que le fichier .htaccess existe et il est accessible (pour l’utilisateur ww-data en principe) ?
Une erreur 403 signifie peut être juste que le .htaccess force le rejet (deny from all dans ce fichier interdit l’accès) et dans ce cas je ne vois pas le rapport avec l’accès SSH (et encore moins avec un problème matériel du coup)
Et une requête en erreur 403 devrait laisser une trace dans le log de jeedom http.errors, est-ce le cas ?

Pour la connexion ssh, quelle est l’erreur du coup ?

1 « J'aime »

Bonjour !
@Fabrice sur le papier cette solution est effectivement « facile ». Seulement elle sous-entend que je n’ai que Jeedom qui tourne sur mon RPI, ce qui n’est pas le cas.
De plus, il ne me semble pas « normal » de devoir formater tout un système (quel qu’il soit) car une application rencontre un souci… Rétablis-tu la configuration d’usine sur ton smartphone à chaque plantage d’une application (dont tu as besoin) ?.. Personnellement, non :). Donc comme je te l’ai dit, je la garde sous le coude, mais uniquement en dernier recours ^^.

@pifou merci pour ta réponse :).
L’erreur en SSH est : error: kex_exchange_identification: Connection closed by remote host

locate .htaccess
[...]
/var/www/html/.htaccess
[...]

Comme je l’ai dit juste avant, j’ai, hier, joué les deux commandes :

chmod 775 -R /var/www/html
chown www-data:www-data -R /var/www/html

Le propriétaire du fichier est donc bien www-data, comme tu le préconises :), cependant root en était le propriétaire !

Le contenu du fameux http.error (pour la journée d’hier) :

[Tue Dec 15 06:25:42.655397 2020] [mpm_prefork:notice] [pid 809] AH00171: Graceful restart requested, doing restart
[Tue Dec 15 06:25:44.876163 2020] [mpm_prefork:notice] [pid 809] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 06:25:44.876236 2020] [core:notice] [pid 809] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 15 14:17:12.960685 2020] [mpm_prefork:notice] [pid 803] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 14:17:12.972626 2020] [core:notice] [pid 803] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 15 16:17:11.390734 2020] [mpm_prefork:notice] [pid 787] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 16:17:11.395299 2020] [core:notice] [pid 787] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 15 16:17:13.040016 2020] [mpm_prefork:notice] [pid 779] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 16:17:13.041762 2020] [core:notice] [pid 779] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 15 18:17:13.135717 2020] [mpm_prefork:notice] [pid 792] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 18:17:13.136883 2020] [core:notice] [pid 792] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 15 18:17:13.958450 2020] [mpm_prefork:notice] [pid 809] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 18:17:13.988842 2020] [core:notice] [pid 809] AH00094: Command line: '/usr/sbin/apache2'
[Tue Dec 15 20:25:29.282977 2020] [mpm_prefork:notice] [pid 809] AH00169: caught SIGTERM, shutting down
[Tue Dec 15 20:25:29.700736 2020] [mpm_prefork:notice] [pid 19410] AH00163: Apache/2.4.25 (Raspbian) OpenSSL/1.0.2u configured -- resuming normal operations
[Tue Dec 15 20:25:29.700968 2020] [core:notice] [pid 19410] AH00094: Command line: '/usr/sbin/apache2'

J’ai eu trois fois cette erreur hier, et pourtant je ne vois rien qui explique cela dans ce fichier :confused:, peut-être peux-tu m’aider à mieux le comprendre ?

Je ne maîtrise pas bien Apache, je ne suis que Développeur :sweat_smile:… En lisant la documentation du .htaccess je comprends que ce fichier est redondant avec apache2.conf… Et qu’il n’est pas « nécessaire » (même plutôt « pas recommandé »)…

Deux questions me viennent donc à l’esprit :

  • S’il n’est pas nécessaire, pourquoi est-ce que je rencontre cette erreur ?
  • Comment puis-je configurer apache pour qu’il se passe donc de ce fichier ?

Je n’ai pas rencontré l’erreur depuis hier 20h. Peut-être que la solution était le chown, dans tous les cas, on apprend plein de choses :smiley:

Encore merci pour votre temps et vos réponses !

Salut,

Ce qui n’est pas recommandé c’est de faire tourner différents services en parallèle de Jeedom (y compris l’environnement de bureau)… D’autant plus sur un Pi.

De plus il me semble que Jeedom remet les droits sur les fichiers à plat chaque nuit. Il existe également un bouton pour le faire directement depuis la configuration Jeedom :
image

Avec tout ça, si les droits ont sauté ça semble uniquement lié à ton installation et à ce qu’il se passe dessus et en aucun cas du fait de Jeedom ou des fichiers .htaccess. Ce n’est d’ailleurs peut-être que la partie émergée de l’iceberg…

Donc plutôt que de continuer à partir dans les mauvaises pratiques en choisissant l’option de modifier la conf apache, le mieux selon moi serait de repartir sur une installation propre comme l’a conseillé @Fabrice dès le début.

1 « J'aime »

ha ne sois pas insultant envers les développeurs hein :smirk:

ton erreur ssh indique un problème de clés SSH, peux-tu te connecter, la prochaine fois que tu a cette erreur, en debug: ssh -vvv usefr@ip pour avoir plus d’infos sur ce problème ? Quelle version debian as-tu ? quelle config SSH ? peut-être une simple mise-à-jour du système (apt update et apt upgrade je sais plus dans quel ordre) suffira à corriger le problème… Sinon, investiguer dans la conf SSH:

# ssh -V
# cat /etc/ssh/sshd_config 

Le fichier .htaccess était sans doute une mauvaise piste, en effet s’il y a un pb sur l’accès SSL -TLS tout ça la ça impacte autant la connexion SSH que HTTPS.
Ha, oui, comment te connecte-tu sur ton jeedom ? Peux-tu y accéder en HTTP simple sur son IP dans le secure la prochaine fois qu’il plante ainsi ?

1 « J'aime »

Loin de moi cette idée, je suis développeur. J’essaie surtout de ne pas être insultant envers nos amis OPS :wink:

Merci pour le mode debug du ssh, je n’y avais pas pensé :sweat_smile:, je teste ça dés que j’ai à nouveau l’erreur !

Distributor ID: Raspbian
Description: Raspbian GNU/Linux 9.13 (stretch)
Release: 9.13
Codename: stretch

Arf, étant nouvel utilisateur je ne peux pas ajouter de fichier :confused:, je peux te l’envoyer en MP si tu le souhaites.

Je joue très régulièrement (pratiquement chaque fois que je me connecte en ssh) un script qui fait :

sudo apt-get upgrade
sudo apt-get update
sudo apt dist-upgrade
sudo apt-get clean

Tout est donc plutôt à jour de ce côté.

Effectivement, c’est une très bonne remarque ! Le souci sur le .htaccess n’est peut-être qu’un effet de bord d’un souci sur l’accès SSL - TLS !

J’y accède par deux moyens :

  • Son IP sur réseau locale (depuis mon réseau local donc)
  • Mon nom de domaine ovh
    Je ne me rappelle plus si j’ai également le forbidden via l’IP locale, il faut que je vérifier lors de la prochaine erreur ! Encore une bonne piste !!

Qu’entends-tu par :

Peux-tu y accéder en HTTP simple sur son IP dans le secure

Merci beaucoup pour vos réponses et votre aide ! C’est très appréciable !!
Et en plus, j’apprends plein plein plein de choses !!

Bonsoir,
apt update doit être réalisé avant apt upgrade.
apt upgrade seul… attend une réponse, donc cela ne doit rien faire chez vous.
La bonne commande est donc :
sudo apt update && sudo apt upgrade -y
apt-get est déprécié (il faut utiliser apt maintenant)

dist-upgrade ne doit pas fonctionner chez vous, sinon pour ne seriez pas en version 9.x il me semble, mais en version 10.

Merci @Fabrice :pray: ! J’ai mis à jour mon script avec la bonne commande !

$ sudo apt dist-upgrade
Reading package lists... Done
Building dependency tree
Reading state information... Done
Calculating upgrade... Done
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

Cela semble fonctionner correctement, mais je me trompe peut-être (sûrement d’ailleurs, mes commandes n’étaient déjà pas bonnes :laughing:)…

Encore merci !

je voulais juste dire, pas en HTTPS :wink:

Bon, quand tu aura résolu ton pb, il faudra quand même penser à migrer sous buster un de ces 4 :smiley:

C’est le cas si /etc/apt/sources.list est modifié avec la liste des dépôts de buster.
Sinon cela met à jour la version de stretch (par exemple 9.8 vers 9.9).

1 « J'aime »

Oui j’ai lu, c’est aussi pas recommandé pour les environnements stables, car cela mets à jour les dépendances.
Je serai @HakunA, je supprimerai cette ligne du script. Qui à mon avis attend aussi un retour.

Hello,

@Fabrice je viens de comprendre ce que tu entendais par « attend un retour », c’est en fait « demande une saisie à l’utilisateur » (dans le cas présent Y/N pour valider).
Et je te confirme que cela fonctionne très bien dans un script. J’aurais peut-être pu/du préciser que je ne passe pas par Jeedom pour exécuter ce script.

@Jeandhom merci pour l’information :).

Question bonus (@pifou tu me recommandes de migrer vers Buster) : L’upgrade de Stretch vers Buster est-il « safe » ?
Il y a encore quelques temps il était vivement et fortement conseillé de partir d’une clean install de Buster plutôt que d’upgrader depuis Stretch.
Est-ce toujours le cas ?

Merci.

P.S : toujours pas de 403 forbidden depuis mardi.


EDIT

Ah, bah il suffit de dire

J’ai pas eu de 403 forbidden depuis mardi

Pour en avoir !

  • Accès Jeedom via HTTPS => KO

Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

  • Accès Jeedom via HTTP => KO

Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

  • L’accès via HTTP de mon autre ressource (ha-bridge) tournant sur mon RPI ==> KO

ERR_CONNECTION_REFUSED

  • Accès en SSH => KO
$ ssh -vvv hakuna@192.168.X.X
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/Hakuna/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.X.X is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.X.X [192.168.X.X] port 22.
debug1: Connection established.
debug1: identity file /Users/Hakuna/.ssh/id_rsa type 0
debug1: identity file /Users/Hakuna/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_dsa type -1
debug1: identity file /Users/Hakuna/.ssh/id_dsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_ecdsa type -1
debug1: identity file /Users/Hakuna/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_ed25519 type -1
debug1: identity file /Users/Hakuna/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_xmss type -1
debug1: identity file /Users/Hakuna/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
kex_exchange_identification: read: Connection reset by peer

D’autres pistes à explorer avant que je fasse un hard reboot ?

Merci !

1 « J'aime »

Bonjour, je relance le sujet…

Après un uptime de 11 jours, j’ai à nouveau eu le souci… :sweat_smile:

  • Accès Jeedom via HTTPS => KO

Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

  • Accès Jeedom via HTTP => KO

Forbidden
You don’t have permission to access this resource.Server unable to read htaccess file, denying access to be safe

  • L’accès via HTTP de mon autre ressource (ha-bridge) tournant sur mon RPI ==> KO

ERR_CONNECTION_REFUSED

  • Accès en SSH => KO
$ ssh -vvv hakuna@192.168.X.X
OpenSSH_8.1p1, LibreSSL 2.7.3
debug1: Reading configuration data /Users/Hakuna/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 47: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.X.X is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.X.X [192.168.X.X] port 22.
debug1: Connection established.
debug1: identity file /Users/Hakuna/.ssh/id_rsa type 0
debug1: identity file /Users/Hakuna/.ssh/id_rsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_dsa type -1
debug1: identity file /Users/Hakuna/.ssh/id_dsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_ecdsa type -1
debug1: identity file /Users/Hakuna/.ssh/id_ecdsa-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_ed25519 type -1
debug1: identity file /Users/Hakuna/.ssh/id_ed25519-cert type -1
debug1: identity file /Users/Hakuna/.ssh/id_xmss type -1
debug1: identity file /Users/Hakuna/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1
kex_exchange_identification: read: Connection reset by peer

J’ai profité de cette erreur pour faire un hard reboot et en même temps mettre dtoverlay=sdtweak,poll_once

Et je constate déjà une belle diminution du load CPU ! Peut-être que ça va m’aider :crossed_fingers:

Je vais tenter l’upgrade vers Buster dans les prochains jours, pour voir si cela résout le souci…

Bonne journée !

EDIT
Bah ça aura tenu moins de deux heures…
A nouveau la même erreur, et exactement le même comportement si je tente l’accès HTTP, HTTPS ou SSH…

Bonjour,

Pour ceux qui on un SSD sur le Raspberry Pi
Alors, il ne faut plus utiliser :
dtoverlay=sdtweak,poll_once
Mais :
dtparam=sd_poll_once
(le fil est mis à jour vers le bas)

=> Si l’ancienne commande marche chez vous, c’est que votre distribution Pi n’est pas à jour !

Enfin, pour vos problèmes d’accès, je comprends que votre Pi sert à autre chose que Jeedom, ce qu’il ne faut pas faire.
=> Surtout s’il y un lien avec les accès au réseau

Hébergez cette ressource ailleurs et vous devriez retrouver un système stable.

Hello all,

@Fabrice pour l’info, je vais tester avec la nouvelle commande (dtparam=sd_poll_once)!
Hier soir j’ai désactiver l’autre ressource (ha-bridge) qui tourne sur mon pi, mais j’ai tout de même eu une 403 en plein milieu de la nuit…
J’ai trouvé quelque chose d’étrange dans /var/log/syslog :

Dec 31 01:47:01 raspberrypi CRON[16703]: (www-data) CMD (/usr/bin/php /var/www/html/core/php/jeeCron.php >> /dev/null)
Dec 31 01:47:01 raspberrypi CRON[16704]: (pi) CMD (su --shell=/bin/bash - www-data -c '/usr/bin/php /var/www/html/jeedom/core/php/jeeCron.php' >> /dev/null 2>&1)
Dec 31 01:47:01 raspberrypi CRON[16707]: (root) CMD (su --shell=/bin/bash - www-data -c '/usr/bin/php /var/www/html/jeedom/core/php/jeeCron.php' >> /dev/null 2>&1)
Dec 31 01:47:01 raspberrypi systemd[1]: Started Session c848 of user www-data.
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@$
Dec 31 01:17:05 raspberrypi fake-hwclock[96]: Thu 31 Dec 00:17:01 UTC 2020
Dec 31 01:17:05 raspberrypi systemd[1]: Started Create Static Device Nodes in /dev.
Dec 31 01:17:05 raspberrypi systemd[1]: Starting udev Kernel Device Manager...
Dec 31 01:17:05 raspberrypi systemd-fsck[133]: e2fsck 1.43.4 (31-Jan-2017)
Dec 31 01:17:05 raspberrypi systemd-fsck[133]: rootfs: clean, 864540/3853696 files, 4083018/15579648 blocks
Dec 31 01:17:05 raspberrypi systemd[1]: Started File System Check on Root Device.
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Remount Root and Kernel File Systems...
Dec 31 01:17:05 raspberrypi systemd[1]: Started udev Kernel Device Manager.
Dec 31 01:17:05 raspberrypi systemd[1]: Started Set the console keyboard layout.
Dec 31 01:17:05 raspberrypi systemd[1]: Started Remount Root and Kernel File Systems.
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Flush Journal to Persistent Storage...
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Load/Save Random Seed...
Dec 31 01:17:05 raspberrypi systemd[1]: Reached target Local File Systems (Pre).
Dec 31 01:17:05 raspberrypi systemd[1]: tmp-jeedom.mount: Directory /tmp/jeedom to mount over is not empty, mounting anyway.
Dec 31 01:17:05 raspberrypi systemd[1]: Mounting /tmp/jeedom...
Dec 31 01:17:05 raspberrypi systemd[1]: Starting udev Coldplug all Devices...
Dec 31 01:17:05 raspberrypi systemd[1]: Mounted /tmp/jeedom.
Dec 31 01:17:05 raspberrypi systemd[1]: Started Load/Save Random Seed.
Dec 31 01:17:05 raspberrypi mtp-probe: checking bus 1, device 8: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.4"
Dec 31 01:17:05 raspberrypi systemd[1]: Started udev Coldplug all Devices.
Dec 31 01:17:05 raspberrypi mtp-probe: checking bus 1, device 3: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.1"
Dec 31 01:17:05 raspberrypi systemd[1]: Starting Show Plymouth Boot Screen...
Dec 31 01:17:05 raspberrypi mtp-probe: bus: 1, device: 8 was not an MTP device
Dec 31 01:17:05 raspberrypi systemd[1]: Started Show Plymouth Boot Screen.
Dec 31 01:17:05 raspberrypi mtp-probe: checking bus 1, device 6: "/sys/devices/platform/soc/3f980000.usb/usb1/1-1/1-1.3/1-1.3.2"
Dec 31 01:17:05 raspberrypi systemd[1]: Reached target Encrypted Volumes.
Dec 31 01:17:05 raspberrypi mtp-probe: bus: 1, device: 6 was not an MTP device
Dec 31 01:17:05 raspberrypi systemd[1]: Reached target Paths.
Dec 31 01:17:05 raspberrypi kernel: [    0.000000] Booting Linux on physical CPU 0x0
Dec 31 01:17:05 raspberrypi kernel: [    0.000000] Linux version 4.19.66-v7+ (dom@buildbot) (gcc version 4.9.3 (crosstool-NG crosstool-ng-1.22.0-88-g8460611)) #1253 SMP Thu Aug 15 11:49:46 BST 2019
  1. L’heure passe de 1h47 à 1h17
  2. Le system semble déclencher un reboot
  3. Après la ligne
    Dec 31 01:18:02 raspberrypi systemd[1907]: Startup finished in 188ms.

Je constate des logs sur ntpd puis, absolument plus aucun signe de vie jusqu’au hard reboot que j’ai du faire ce matin en constatant la 403 :

Dec 31 01:18:02 raspberrypi systemd[1907]: Startup finished in 188ms.
Dec 31 01:18:02 raspberrypi systemd[1]: Started User Manager for UID 33.
Dec 31 01:18:14 raspberrypi ntpd[546]: Soliciting pool server 212.83.145.32
Dec 31 01:18:14 raspberrypi ntpd[546]: Soliciting pool server 212.83.158.83
Dec 31 01:18:14 raspberrypi ntpd[546]: Soliciting pool server 162.159.200.123
Dec 31 01:18:15 raspberrypi ntpd[546]: Soliciting pool server 54.36.60.132
Dec 31 01:18:15 raspberrypi ntpd[546]: Soliciting pool server 212.85.158.10
Dec 31 01:18:15 raspberrypi ntpd[546]: Soliciting pool server 129.250.35.250
Dec 31 01:18:16 raspberrypi ntpd[546]: Soliciting pool server 51.15.182.163
Dec 31 01:18:16 raspberrypi ntpd[546]: Soliciting pool server 129.250.35.251
Dec 31 01:18:16 raspberrypi ntpd[546]: Soliciting pool server 51.158.147.92
Dec 31 01:18:17 raspberrypi ntpd[546]: Soliciting pool server 62.210.206.214
Dec 31 01:18:17 raspberrypi ntpd[546]: Soliciting pool server 188.165.224.178
Dec 31 01:18:17 raspberrypi ntpd[546]: Soliciting pool server 212.51.181.242
Dec 31 01:18:18 raspberrypi ntpd[546]: Soliciting pool server 82.64.95.3
Dec 31 01:18:19 raspberrypi ntpd[546]: Soliciting pool server 51.158.67.116
Dec 31 01:18:19 raspberrypi systemd[1]: Stopping LSB: Start NTP daemon...
Dec 31 01:18:19 raspberrypi ntpd[546]: ntpd exiting on signal 15 (Terminated)
Dec 31 01:18:19 raspberrypi ntpd[546]: 212.83.158.83 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 162.159.200.123 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 129.250.35.250 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 54.36.60.132 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 212.85.158.10 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 51.15.182.163 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 129.250.35.251 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 51.158.147.92 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 188.165.224.178 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 212.51.181.242 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 62.210.206.214 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 82.64.95.3 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntpd[546]: 51.158.67.116 local addr 192.168.31.16 -> <null>
Dec 31 01:18:19 raspberrypi ntp[2874]: Stopping NTP server: ntpd.
Dec 31 01:18:19 raspberrypi systemd[1]: Stopped LSB: Start NTP daemon.
Dec 31 05:57:29 raspberrypi systemd[1]: Time has been changed
Dec 31 05:57:29 raspberrypi ntpdate[2899]: step time server 51.15.182.163 offset 16742.537738 sec
Dec 31 05:57:29 raspberrypi systemd[1907]: Time has been changed

Je me demande donc :

  1. Qu’est-ce qui explique ce changement d’heure système si soudain ?
  2. D’où proviennent les ^@ qui sont affichés PILE au moment du changement d’heure ?
  3. Que dois-je chercher dans les logs afin d’avoir une piste sur la raison du reboot ?

Merci, et bon réveillon !