Domanda:
WatchDog Daemon non riavvia PI dopo fork bomb
Richard
2012-11-26 19:51:15 UTC
view on stackexchange narkive permalink

Ho provato a eseguire il demone WatchDog utilizzando il tutorial disponibile su http://binerry.de/post/28263824530/raspberry-pi-watchdog-timer

Quindi Il processo di base che ho seguito per far funzionare WatchDog è:

  1. sudo modprobe bcm2708_wdog2. sudo nano / etc / modules (aggiungi la riga "bcm2708_wdog") 3. apt-get install watchdog chkconfig4. watchdog chkconfig on5. /etc/init.d/watchdog start6. nano /etc/watchdog.conf (abilita la riga "watchdog-device = / dev / watchdog")  

Quando riavvio vedo che il demone WatchDog si avvia in una delle ultime attività di avvio del sistema , tuttavia quando provo una bomba a forcella, il sistema diventa inutilizzabile ma non si ripristina mai.

Utilizzare il codice della bomba a forcella di seguito: (Avviso per gli altri che leggono, il codice sotto può causare danni. Leggi il tutorial collegato in alto per maggiori informazioni)

  #! / bin / bash: () {: |: &} ;:  
Consiglio anche di controllare il networking: /etc/watchdog.conf ping = interface = eth0 interval = 20 realtime = yes priority = 1 watchdog-device = / dev / watchdog
Quattro risposte:
#1
+5
Michael
2012-11-26 21:53:16 UTC
view on stackexchange narkive permalink

a) per un forkbomb efficace è necessario disabilitare la partizione di swap. (swapoff -a) b) il sistema può sopravvivere a una singola forkbomb. Basta avviarne un certo numero.

Un test molto semplice può essere eseguito uccidendo il processo di watchdog. In questo modo il processo watchdog non esegue il ping del dispositivo watchdog, quindi il watchdog hardware riavvierà il pi. In una situazione del mondo reale, il demone watchdog non è in grado di eseguire il ping di nulla a causa dell'elevato carico del sistema. Il risultato sarebbe il riavvio dell'hardware.

Ho disattivato lo scambio e ho lasciato funzionare il processo per un po 'ma l'unità non si è riavviata. più fork bomb sarebbero più efficaci di una sola? Penserei che otterresti lo stesso risultato con uno solo (davvero non lo so, solo per la mia conoscenza limitata su come funzionano le forcelle).
#2
+5
berto
2018-12-27 11:45:13 UTC
view on stackexchange narkive permalink

Ho passato un po 'di tempo a far funzionare il watchdog su una versione Debian Stretch di Raspbian:

  pi @ orangepi: ~ $ cat / etc / rpi-issue Riferimento a Raspberry Pi 2018-11- 13 Generato utilizzando pi-gen, https://github.com/RPi-Distro/pi-gen, 7e0c786c641ba15990b5662f092c106beed40c9f, stage2pi @ orangepi: ~ $ uname -aLinux orangepi 4.14.79-v7 + # 1159 SMP Sun Nov 4 17:50:20 GMT 2018 armv7l GNU / Linux  

Si scopre che è abbastanza semplice e non richiede nemmeno il pacchetto watchdog aggiuntivo. Utilizza invece le funzionalità watchdog di Systemd.

Modifica il file /etc/systemd/system.conf e imposta le seguenti opzioni:

  RuntimeWatchdogSec = 10ShutdownWatchdogSec = 10min  

Salva il file, riavvia e prova la fork bomb:

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

circa 30 secondi la shell esce e, dopo aver effettuato nuovamente l'accesso, il tempo di attività viene ripristinato:

  pi @ orangepi: ~ $ uptime 05:43:16 su 1 min, 1 utente, caricamento medio: 0,38, 0,12, 0,04  
dopo un paio di giorni da hobbista, non ho ancora provato la cosa: () {: |: &} ;:. Quindi ho cercato su Google e ho trovato la tua risposta qui. Le cose sono in realtà più complicate di quanto pensassi, quindi mi servono almeno un paio di giorni in più.
#3
+4
Richard
2012-11-26 20:46:08 UTC
view on stackexchange narkive permalink

Ho una teoria sul motivo per cui il sistema non si riavvia, ma non è ancora stato testato.

in /etc/watchdog.conf ci sono righe:

  realtime = yespriority = 1  

fondamentalmente quello che sto pensando è che il forkbomb gira ma con una priorità inferiore a 1. WatchDog Daemon è ancora in grado di inviare gli impulsi all'hardware WatchDog. Il sistema è ancora in esecuzione piuttosto inutilizzabile, ma poiché WatchDog Daemon ha una priorità così alta, è felice.

nello stesso file di configurazione c'è una riga:

  max- load-1 = 24  

Ho decommentato questa riga e ora WatchDog Daemon funziona come previsto.

L'unico problema qui è che è possibile riavviare la macchina quando non è veramente bloccata. Nel mio caso, non sto eseguendo lxde e solo alcuni processi cron Python che non sono affamati di risorse, quindi non dovrebbe essere un problema per me.

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

Ho avuto la stessa esperienza eseguendo il fork-bomb - il sistema è diventato instabile - e mi ha cacciato dalla mia sessione ssh - ma il pi non si è riavviato.

L'ho fatto funzionare (a almeno una volta) tuttavia, eseguendo la fork-bomb come root.

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


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...