Topic: [risolto] Watchdog su linux rig, consigli? - page 2. (Read 2957 times)

Hai due strade:

- Modifichi manualmente i link in rc3.d impostando un numero più alto di startup e facendolo eseguire dopo il network

- Non lo fai partire in automatico al boot ma lo lanci da rc.local (che è l' ultimo ad essere eseguito a macchina avviata)


Senza dilungarmi troppo, i demoni vengono eseguiti nell' ordine che trovi nel link simbolico, dal numero 1 al numero 99, quindi ti basta vedere a che livello (numero) parte il network per farlo poi partire dopo.

O mamma, 14 risposte?
che cosa ho scatenato?

Le mie necessità al momento sono molto modeste.
Controllare che sia attiva una connessione internet e nel caso riavviare, capita infatti che ogni tanto la chiavetta 3g si blocchi. Ovviamente se il sistema si riavvia anche nel caso di freeze ecc, meglio ancora.

Per questo motivo stavo guardando lo watchdog software sebbene, sfortunatamente, non funziona come dovrebbe.
Mi capita la stessa cosa riportata nel link del mio primo post.
Il demone si avvia al boot ma al boot la chiavetta internet 3g non è stata ancora inizializzata, quindi il ping scade e il sistema entra in un ciclo di reboot infinito.

Disabilitando l'avvio di watchdog al boot, il sistema si avvia, solo che poi non so come avviare in automatico il demone dopo il login.

uno script di questo tipo:


piazzato in /usr/bin e richiamato da un file .desktop in autostart... Non funziona (teamviewer parte ma il watchdog no).
Qualche suggerimento? se riuscissi a far partire il watchdog al login mi andrebbe più che bene.
L'idea di un watchdog hardware (se ho capito la proposta di bertani) è troppo complessa per me ora, quello software sarebbe più che sufficiente se funzionasse


Che sono le stesse cose che utilizzo io
Tuttavia se si pianta la connessione c'è poco da fare (con la chiavetta ho notato che succede ogni tanto), per questo mi serviva un watchdog sul ping.
Poi fin tanto che il sistema è online lo gestisco o tramite ssh o tramite teamweaver.

Mi sembra improbabile, ma lo possiamo sempre verificare 

Appunto, anche se si blocca la CPU i layer dal 3 in giù continuano a funzionare quindi se pinghi ottieni risposta anche se la macchina è bloccata (perchè la scheda di rete resta comunque in piedi fintanto che non gli viene tolta l'alimentazione)

I layer sono intesi al contrario, ovvero scendono più ti avvicini all' hardware. Di conseguenza è più facile che reagisca a layer più bassi che il contrario.
Puoi sempre costruire un piccolo firmware ad hoc che faccia il controllo sul socket di cgminer ed estrapolare la velocità di mining, che se pari a zero (o se non ricevuta propio) attivi il relè. Chiaramente il controllo và fatto con un delay sufficiente per far si che la macchina abbia il tempo di riavviarsi, o entri in un loop infinito.

Un telnet sulla porta delle API di Cgminer risolve ogni dilemma, dando per inteso che si deve aprire questa porta: si verificherà sia l'up della macchina che lo status di listening di cgminer.

Eh no.. se si inchioda la cpu i layer dal 3 in giù vengon comunque gestiti dal micro sul controller ethernet, quello è il punto.. (potrei sbagliarmi, ma mi sembra di ricordare questa cosa da delle prove che avevo fatto anni fa)

Certo che è un Layer3, puoi scendere a Layer2 con broadcast ARP ma a che pro ? Se la macchina si inchioda, si inchioda su tutti i Layer. Senza contare che se configuri Arduino per benino (hehehe) puoi sempre entrarci da remoto e riavviare a manina (o via SMS  )

Ehm.. occhio che se non ricordo male ping (protocollo ICMP) è appena layer3..

Uhmm un Arduino con un relè sul pulsante di reset e un ping (o un telnet) dovrebbe bastare 

Pardon Bertani se ho letto male il tuo post (l'ho letto l'ho letto non era troppo lungo, solo che ero di primo risveglio mattutino). Me scusi.. ostia...  

In ogni modo poi dipende dalla stabilità del server. Il mio Debian è da 3 anni acceso e mai riavviato, però capisco l'esigenza e ovviamente avere più certezze, sopratutto se magari non si ha la possibilità d'operare localmente, è buona cosa.

Sì Guido, l'alternativa è un relè esterno, solo per i veri duri

Stavo elaborando una cosa diabolica che prevedeva un temporizzatore, il mitico Coffee-Howto, un costante conto alla rovescia e Dio solo sa cos'altro, ma la verità è che fare un watchdog hardware elettromeccanicamente risulta più complicato, meno ortodosso e anche meno efficace dell'usare un comunissimo Arduino.

ziomik non hai letto il mio post vero? TL;DR, vero..
Come dicevo sopra, con una soluzione come quella che proponi tu qui, se si inchioda la macchina non hai modo di riavviarla.

Troppo paranoico? E invece no, cito da cgminer/GPU-README:

Quando succede questa cosa non c'è speranza, sotto linux, di riavviare automaticamente il sistema perchè il driver ati impazzisce (per un bug evidentemente, maledetti driver closed..) e molto spesso questo porta a un consumo della CPU 100% da parte del kernel: la macchina si blocca e il tuo bel scriptino cron non si avvierà e anche se ce la facesse.. in bocca al lupo per portare a termine il reboot, in questa situazione io via software non ce l'ho mai fatta.
Per questo motivo avrebbe più senso tenere un demone che:
* tiene aperto /dev/watchdog prendendosi così in carico l'effettivo refresh del watchdog
* ci scrive dentro qualcosa ogni N secondi (con N minore del timeout T del watchdog, tipicamente T~60) dopo aver tentato di recuperare la situazione, sempre se qualcosa è andato storto

Esempio concreto [N = 30], stiamo usando cgminer, tutto va bene e ogni 30 secondi il nostro scriptino riazzera il watchdog. Una GPU va in DEAD. Lo scriptino se ne accorge perchè vede che l'hashrate è molto inferiore di quel che dovrebbe (o se ne accorge in altro modo, a vostra discrezione), prova a chiudere cgminer (per poi riaprirlo o per riavviare, cambia nulla, deve pur essere chiuso), il driver va in stallo e la CPU pure (vedi sopra). Pure il nostro scriptino si blocca, il watchdog non viene refreshato e appena va i timeout fa un hard-reset e riparte tutto in automatico 

na cosa così da avviare ogni x con crontab, no ?

lol la discussione che hai linkato è ridicola..


A me non sembra affatto un'alternativa, se nello script intendi dare un reboot all'occorrenza... Stando così ad alto livello diventa un problema in caso di freeze (che non è raro specialmente se hai una configurazione non stabilissima con le gpu - cosa che necessita del tempo per essere verificata) perchè non riusciresti a gestirlo.

L'idea migliore, secondo me, è quella di sfruttare il watchdog hardware tramite linux. Qui c'è la documentazione del caso:
https://www.kernel.org/doc/Documentation/watchdog/watchdog-api.txt
Per farla breve basta far gestire il tick a un processo nello userspace, così quando questo si blocca o non verifica più certe condizioni (e non riesce a fixarle entro un tot) il watchdog va in timeout e si riavvia la macchina in automatico ("hard-reset").
Se si decide di seguire un approccio del genere sarebbe preferible impostare il filesystem in readonly per evitare di danneggiarlo durante questi reboot "non regolari".
Ecco due semplicissimi esempi ufficiali sull'utilizzo del watchdog sotto linux: https://www.kernel.org/doc/Documentation/watchdog/src/

Per quanto riguarda cron, ricorda che ha una sensibilità di 1 minuto quindi non è detto che sia sufficiente per non far andare in timeout il watchdog, considerando che ti serve del tempo (prima di refreshare il watchdog) per verificare dallo script che sia tutto apposto.


windows: teamviewer e simili, linux: ssh

Stavo pensando a uno watchdog per il rig, qualcosa che effettui un reboot se la connessione non è attiva, se il sistema si blocca ecc.

So che debian/ubuntu ha uno watchdog ma sembra che il test della connettività dia qualche problema.
Il ping parte all'avvio quando ancora la connessione di norma non è attiva e la macchina va in in ciclo di riavvio infinito:
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=30&t=20149

Un alternativa potrebbe essere crontab + uno script.
Tuttavia mi chiedevo se esiste qualche pacchetto bello comodo per la gestione di queste cose, magari anche con la GUI

Per chi ha il rig lontano da casa, voi come fate?

Grazie