Avant de vous pencher sur du matériel supplémentaire, veuillez lire ce que l'on appelle un «chronomètre de surveillance». Le Raspberry Pi a un chien de garde matériel intégré qui le redémarrera si la puce n'est pas rafraîchie dans un certain intervalle.

J'ai configuré le chien de garde sur un Raspberry Pi 3 et une nouvelle version de Raspbian avec très peu de configuration. La première chose à vérifier est que le chien de garde matériel est disponible (j'ai vérifié mon système et il ressemble à la version de Raspbian que j'ai installée compile le support du chien de garde directement dans le noyau; pas besoin de charger un module du noyau):

  pi @ unicornpi: ~ $ ls -al / dev / watchdog * crw ------- 1 racine racine 10, 130 3 novembre 2016 / dev / watchdogcrw ------- 1 racine racine 252, 0 3 novembre 2016 / dev / watchdog0  

Si vous voyez / dev / watchdog , vous êtes prêt. Tout ce que vous avez à faire est de configurer la fonction de surveillance intégrée à Systemd.

Dans le fichier /etc/systemd/system.conf , définissez les lignes suivantes:

  pi @ unicornpi: ~ $ grep Watchdog /etc/systemd/system.confRuntimeWatchdogSec=10ShutdownWatchdogSec=10min

Ce que disent les lignes ci-dessus est:

• actualise le chien de garde matériel toutes les 10 secondes. si pour une raison quelconque le rafraîchissement échoue (je crois après 3 intervalles; c.-à-d. 30 s), redémarrez le système

• à l'arrêt, si le système prend plus de 10 minutes pour redémarrer, cycle le système

Une fois que vous avez configuré et redémarré, vous verrez quelque chose comme ça dans les journaux dmesg :

  pi @ orangepi: ~ $ dmesg | grep -i watchdog [0.763148] bcm2835-wdt 3f100000.watchdog: Broadcom BCM2835 watchdog timer [1.997557] systemd [1]: Hardware watchdog 'Broadcom BCM2835 Watchdog timer', version 0 [2.000728] systemd [1]: Réglez le watchdog matériel sur 10s .  

Si vous voyez Set hardware watchdog sur 10s , vous êtes prêt.

Le meilleur moyen que j'ai trouvé pour vérifier que le chien de garde fonctionne est de surcharger le système. J'ai fait cela avec une "bombe de fourche", qui saturera complètement le système avec des fourches de processus d'ordures. Si vous exécutez cela, le Pi ne répondra plus et le chien de garde devrait démarrer. Votre système devrait être à nouveau opérationnel après environ une minute:

 : () {: |: &} ;: 

Collez cela dans un shell et votre système sera arrêté. Vous avez été averti.

Pour plus d'informations sur le système de surveillance intégré à Systemd, consultez le site Web de l'auteur.

La puissance de coupe est une méthode de force brute et comporte des risques.

La solution conventionnelle aux problèmes de verrouillage est d'utiliser un chien de garde.

Il existe un chien de garde du matériel BCM; Si vous souhaitez démarrer le chien de garde matériel, incluez dtparam = watchdog = on dans /boot/config.txt

En et en soi, cela ne fait pas grand-chose, bien qu'il devrait redémarrer le système si pas "kické" régulièrement. Vous pouvez écrire du code qui ouvre / dev / watchdog pour le lancer.

Il existe également un démon watchdog que vous pouvez configurer pour activer le watchdog; vous devriez pouvoir commencer avec sudo systemctl enable watchdog

PS Par ailleurs, si vous voulez poursuivre l'approche de la force brute - ne vous inquiétez pas de couper l'alimentation - tirez simplement sur la broche de réinitialisation (étiqueté RUN ) faible. Cela équivaut à éteindre puis rallumer.

Question[

Le gel des Rpi à distance de temps en temps. Comment les réveiller?

Réponse

Mise à jour 2019jul27hkt1406

J'ai récemment mis à jour mon Rpi3B + stretch vers Rpi4B buster et encore une fois j'ai suivi le tutoriel de @ berto pour régler la minuterie du chien de garde. J'ai trouvé que tout fonctionnait aussi bien qu'avant. En d'autres termes, aucune modification n'est nécessaire dans le didacticiel de @ berto lors de la mise à niveau vers Rpi4.

La dernière fois, je ne savais rien de la minuterie de surveillance. Il m'a donc fallu plus de 3 heures pour google pour tout comprendre à l'intérieur (enfin, presque à l'envers). Cette fois, je sais ce qui se passe et toutes les astuces Linux, donc il ne m'a fallu que quelques minutes pour terminer le tutoriel de @ berto.

Mises à jour 2019jun18

Après quelques réflexions, j'ai conclu que ma réponse touche à sa fin. Ma conclusion est que le tutoriel de surveillance et la suggestion d'expérimentation de @ berto sont bons, et sa réponse est la vraie réponse à la question du PO.

J'ai fait son expérience suggérée avec succès, vérifié les résultats par le programme forkbomb, et après beaucoup de recherches sur Google et de lecture pendant plus de 10 heures, je pense que j'ai finalement bien compris l'idée de l'horloge de surveillance.

Auparavant, je pensais à tort que je devais encore apprendre à régler la minuterie sur 10 secondes ou plus. Mais comme le dit @berto, il suffit de régler 10 secondes. J'ai également lu que je pouvais régler la minuterie sur 16 secondes et que la valeur par défaut du chien de garde Linux était même d'une minute. Mais ce n'est pas critique.

J'ai supprimé toutes les longues notes de lecture dans les annexes, pour raccourcir la réponse. Je suggérerais aux débutants de ne pas essayer de comprendre tous les détails du chien de garde, sans parler du démon SystemD beaucoup plus compliqué, car notre vie est courte et ces choses système sont trop compliquées pour les non professionnels.

I souhaite ajouter deux points pour terminer ma réponse.

(1) Il existe de nombreuses raisons pour lesquelles un Rpi se bloque dans quelques jours (mais généralement pas des mois). Souvent, ce n'est pas la faute du programme d'application, mais parce que les pilotes ou les fonctions de la bibliothèque créent trop de déchets, par exemple. sockets créés, utilisés mais pas correctement éliminés. Si c'est le programme d'application lui-même qui fait des déchets, le programme peut faire un "garbage collection" et le problème est résolu. Mais il est difficile de supprimer les sockets garbage qui ne sont pas générés par le programme d'application. Une minuterie de surveillance est donc utile ici.

(2) D'autres moyens d'éviter trop de déchets en utilisant les ressources incluent le redémarrage de temps en temps par logiciel ou matériel. Je pense que le redémarrage tous les matins et l'utilisation d'une alimentation commutable par logiciel pour réinitialiser le système ajoutent une autre couche de protection. Et n'utiliser qu'un seul Rpi n'est pas très sûr. L'utilisation de deux Rpi comme chien de garde l'un de l'autre (en utilisant URT pour le passage de messages, par exemple) ajoute une couche de protection supplémentaire. Une autre méthode que je n'ai pas explorée consiste à utiliser les prises Wifi ESP8266. J'espère pouvoir essayer ça plus tard.

C'est la fin de ma réponse. Bravo.

Mises à jour 2019jun17

J'ai donc essayé la bombe à fourche. Le système a redémarré après l'exécution du programme, en environ 15 secondes .

Mises à jour 2019jun16

J'ai trouvé que le programme de bombe à fourche de @ berto est un peu effrayant pour les débutants. J'apprends donc à Bash pour découvrir ce que fait cette bombe à fourche. Fondamentalement, il s'agit simplement d'une fonction nommée ":", qui est définie comme une fonction s'appelant elle-même deux fois, bifurquant ainsi indéfiniment, aussi vite que les lapins croissent de manière exponentielle, utilisent toutes les ressources et plantent Linux.

J'ai également trouvé la version intéressante suivante de forkbomb utilisant des symboles Unicode:

() {| &};

Mises à jour du 14/15 2019

@thesnow suggère une très belle approche en couches utilisant une prise intelligente. Je pense que la prise intelligente ou les trucs IoT intelligents sont la voie à suivre. Cependant, je ne suis pas un débutant si intelligent dans les trucs intelligents, même si je suis désireux d'apprendre. Je vais donc acheter une prise intelligente, faire des recherches et améliorer ma réponse par la suite. Pour l'instant, j'ai ajouté des ressources d'apprentissage connexes dans la section de référence ci-dessous.

J'ai trouvé la suggestion de @ berto d'utiliser le minuteur de surveillance matérielle de Rpi également très bonne. Je n'ai jamais joué avec des trucs de chien de garde auparavant. Alors je vais l'essayer maintenant. Les instructions de @ berto sont très détaillées, mais toujours un peu difficiles pour moi, car je ne connais pas très bien la signification des commandes "grep" et "dmseg". J'ai donc cherché sur Google et pris des notes de lecture dans les annexes ci-dessous. Ensuite, j'ai suivi la suggestion de @ berto, et j'ai eu un peu de mal à terminer la partie 1. Je n'ai pas encore redémarré, car j'ai besoin de faire une pause pour digérer les choses. Quoi qu'il en soit, voici la capture d'écran.

J'ai redémarré et j'ai obtenu le dmesg suivant:

Je pense que je vais trop vite et que je dois maintenant faire une pause pour étudier d'abord plus de choses Linux, comme systemd, avant de revenir pour continuer le test sur watchdog.

/ pour continuer, ...

La réponse

J'ai le même problème. Je construis un jardin sur le toit avec quelques Rpi chacun se connectant à divers capteurs, relais et solénoïdes sans fil (BlueTooth, Wifi). Il y a deux énormes moteurs à proximité, contrôlant de grands réservoirs d'eau et des ascenseurs. Les moteurs génèrent des interférences électromagnétiques et gèlent de temps en temps les objets électroniques à proximité.

Mon plan est d'utiliser des blocs d'alimentation commutables par logiciel (blocs d'alimentation) pour éteindre / rallumer les Rpi et autres appareils gelés (les appareils Bluetooth se bloquent le plus souvent. Le BlueTooth et les autres petits appareils n'ont pas de commande de réinitialisation logicielle ou de réinitialisation matérielle broche, donc éteindre / allumer leur 5V Vcc est un moyen rapide et sale, mais toujours sûr). En bref, les Rpi se regardent régulièrement et leurs appareils et POR (Power On Reset) tout gars tombé en sommeil.

Bien sûr, je peux également utiliser une broche GPIO pour déclencher le matériel Rpi sur la broche de réinitialisation de la carte. Mais je suis trop paresseux pour faire du câblage supplémentaire, et trop pauvre amateur pour me permettre des appareils système non-stop de qualité professionnelle / industrielle tels que le SwitchDoc Labs Dual WatchDog Timer (voir référence ci-dessous)

Je modifie DC- ordinaire. Alimentation CC (12 V à 5 V) afin que toutes les broches GPIO Rpi ou MCP23x17 puissent allumer / éteindre la puce de régulateur de tension LM2956 / LM2947 du bloc d'alimentation. (Le LM2941 peut être utilisé pour les commutateurs de courant 1A, LM2596 pour le bloc d'alimentation 5V 3A. La broche marche / arrêt est également connectée à un bouton-poussoir, pour les tests de mise sous / hors tension manuelle.)

En fait, chacun de mes 7 Le Rpi3B + est connecté à un module d'horloge temps réel DS3231 bon marché qui a une broche d'interruption matérielle pour réinitialiser le bloc d'alimentation, le Rpi ou d'autres périphériques.

Chaque fois que cela est possible et pratique, j'attache toutes les broches de réinitialisation des appareils ensemble (en supprimant certaines des résistances de rappel, afin de ne pas surcharger la broche GPIO).

Maintenant, le DS3231 externe Le RTC réveille tout le monde le matin et éteint les lumières à minuit, pour que tout le monde se couche.

Références

1. PSU / Commutateurs actuels réinitialisables par logiciel basé sur LM2596 / LM2941 - Discussion Rpi StkEx

Discussion sur le chien de garde du matériel Rpi

SwitchDoc Labs Dual WatchDog Minuterie

ATXRaspi R3 - LowPowerLab 14,95 $ US

Un ESP8266 piratable dans une prise intelligente Vous voulez jouer avec l'ESP8266 sans vous soucier de le matériel? - Mat 2017aug06

Reverse Engineering 101 de l'écosystème Xiaomi IoT HITCON Community 2018 - Dennis Giese

Prise WiFi Xiaomi + application MiHome 21 307 vues

espHome [ESP8266 / ESP32]

AliExpress WiFi Smart Plug

Appareil intelligent -Wikipedia

Ouvre-porte de garage WiFi avec ESP8266 - Ray Wang 2016mai13 56335 vues

Annexes

Annexe A - Notes de lecture du WatchDog Timer

Watchdog timer -Wikipedia

Linux Page WatchDog Man

Linux Watchdog - Tests généraux

Annexe B - Notes de lecture des commandes Linux grep et dmesg

Annexe C - Références systemd

Systemd Systemd System and Service Manager - FreeDeskTop

systemd - Wikipédia

Annexe D - Références sur les bombes à fourche et à fourche

Fork (appel système) Wikipédia

Annexe E - Notes d'apprentissage Bash

J'ai pas mal de Pis. Tous, sauf un, ont fonctionné parfaitement. L'enfant à problème plantait périodiquement et ne se remettrait jamais après une panne de courant sans être à nouveau redémarré. Je l'ai fait redémarrer tous les soirs via cron et cela m'a aidé un peu.

Ce qui a résolu le problème était de prendre la carte SD et le matériel du capteur et de les mettre dans un autre Pi. Il a fonctionné sans erreur depuis. Peut-être avez-vous aussi un problème matériel.

Si vous avez le Wi-Fi et que vous avez juste besoin d'éteindre / de rallumer, vous pouvez également envisager d'utiliser une prise intelligente. Amazon en fabrique un pour ~ 25 $, vous pouvez l'allumer / l'éteindre à distance et également configurer des routines de minuterie si cela est préférable. J'en ai quelques-uns depuis plusieurs mois et ils sont assez fiables. Vous n'avez pas besoin d'un Echo ou de tout autre appareil dédié. J'utilise mon téléphone intelligent. Amazon Smart Plug

Modifier: je me rends compte que cela ne fournit pas de solution à la première partie de la question, mais si j'avais la perspective de 2 heures de route si quelque chose se passait faux je considérerais une approche par couches.