Question:
WatchDog Daemon ne redémarre pas PI après une bombe à fourche
Richard
2012-11-26 19:51:15 UTC
view on stackexchange narkive permalink

J'ai essayé d'exécuter le démon WatchDog en utilisant le tutoriel disponible à l'adresse http://binerry.de/post/28263824530/raspberry-pi-watchdog-timer

Donc Le processus de base que j'ai parcouru pour faire fonctionner WatchDog est:

  1. sudo modprobe bcm2708_wdog2. sudo nano / etc / modules (ajoutez la ligne «bcm2708_wdog») 3. apt-get install le chien de garde chkconfig4. chien de garde chkconfig on5. /etc/init.d/watchdog start6. nano /etc/watchdog.conf (activer la ligne «watchdog-device = / dev / watchdog»)  

Quand je redémarre, je vois que le démon WatchDog démarre dans l'une des dernières tâches de démarrage du système , cependant, lorsque j'essaye une bombe à fourche, le système devient inutilisable mais ne se réinitialise jamais.

Utilisation du code de la bombe à fourche ci-dessous: (Attention aux autres lecteurs, le code ci-dessous peut causer des dommages. Lisez le tutoriel lié en haut pour plus d'informations)

  #! / bin / bash: () {: |: &} ;:  
Je recommande également de vérifier le réseau: /etc/watchdog.conf ping = interface = eth0 interval = 20 realtime = yes priority = 1 watchdog-device = / dev / watchdog
Quatre réponses:
#1
+5
Michael
2012-11-26 21:53:16 UTC
view on stackexchange narkive permalink

a) pour un fork efficace, vous devez désactiver la partition d'échange. (swapoff -a) b) le système peut survivre à une seule bombe à fourche. Démarrez simplement un certain nombre d'entre eux.

Un test très simple peut être fait en tuant le processus de surveillance. Ce faisant, le processus de surveillance ne cingle pas le périphérique de surveillance, de sorte que le chien de garde matériel redémarrera le pi. Dans une situation réelle, le démon de surveillance ne peut pas envoyer de requête ping à quoi que ce soit en raison de la charge élevée du système. Le résultat serait le redémarrage du matériel.

J'ai désactivé le swap et laissé le processus s'exécuter pendant un moment, mais l'unité n'a toujours pas redémarré. plusieurs bombes à fourche seraient-elles plus efficaces qu'une seule? Je pense que vous obtiendriez le même résultat avec un seul (je ne sais vraiment pas, juste à partir de mes connaissances limitées sur le fonctionnement des fourches).
#2
+5
berto
2018-12-27 11:45:13 UTC
view on stackexchange narkive permalink

J'ai passé un peu de temps à faire travailler le chien de garde sur une version Debian Stretch de Raspbian:

  pi @ orangepi: ~ $ cat / etc / rpi-issueRaspberry Pi reference 2018-11- 13Généré à l'aide de pi-gen, https://github.com/RPi-Distro/pi-gen, 7e0c786c641ba15990b5662f092c106beed40c9f, stage2pi @ orangepi: ~ $ uname -aLinux orangepi 4.14.79-v7 + # 1159 SMP dim 4 novembre 17:50:20 GMT 2018 armv7l GNU / Linux  

Il s'avère que c'est assez facile et qu'il ne nécessite même pas le paquetage de surveillance supplémentaire. À la place, il utilise les fonctions de surveillance Systemd.

Modifiez le fichier /etc/systemd/system.conf et définissez les options suivantes:

  RuntimeWatchdogSec = 10ShutdownWatchdogSec = 10min  

Enregistrez le fichier, redémarrez et essayez la bombe de fourche:

  pi @ orangepi: ~ $ cat > / tmp / test .sh #! / bin / bash: () {: |: &};: # appuyez sur ctrl + d herepi @ orangepi: ~ $ sudo bash /tmp/test.sh

Après environ 30 secondes, le shell se ferme et lors de la reconnexion, le temps de fonctionnement est réinitialisé:

  pi @ orangepi: ~ $ uptime 05:43:16 jusqu'à 1 min, 1 utilisateur, charge moyenne: 0,38, 0,12, 0,04  
après quelques jours d'amateur, je n'ai toujours pas essayé la chose: () {: |: &} ;:. Alors je google et j'ai trouvé votre réponse ici. Les choses sont en fait plus compliquées que je ne le pensais, donc j'ai besoin d'au moins quelques jours de plus.
#3
+4
Richard
2012-11-26 20:46:08 UTC
view on stackexchange narkive permalink

J'ai une théorie sur les raisons pour lesquelles le système ne redémarre pas, mais pas encore testé.

dans /etc/watchdog.conf il y a des lignes:

  realtime = yespriority = 1  

essentiellement ce que je pense que le forkbomb fonctionne mais à une priorité inférieure à 1. WatchDog Daemon est toujours capable de transmettre les impulsions au WatchDog matériel. Le système fonctionne toujours assez inopérant, mais comme WatchDog Daemon a une telle priorité, il est heureux.

dans le même fichier de configuration, il y a une ligne:

  max- load-1 = 24  

J'ai décommenté cette ligne et maintenant le démon WatchDog fonctionne comme prévu.

Le seul problème ici est qu'il est possible de redémarrer la machine lorsqu'elle n'est pas vraiment bloquée. Dans mon cas, je n'exécute pas lxde et n'exécute que quelques tâches cron python qui ne sont pas gourmandes en ressources, donc cela ne devrait pas être un problème pour moi.

#4
+2
monojohnny
2014-11-08 17:44:11 UTC
view on stackexchange narkive permalink

J'ai eu la même expérience lors de l'exécution du fork-bomb - le système est devenu instable - et m'a lancé ma session ssh - mais le pi n'a pas redémarré.

Je l'ai fait fonctionner (à au moins une fois) cependant - en exécutant la fork-bomb en tant que root.

  $ sudo su - # swapoff -a #: () {: |: &} ;:   pré>


Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 3.0 sous laquelle il est distribué.
Loading...