Topic: [risolto] Watchdog su linux rig, consigli? (Read 2968 times)

Nel mio caso perché a volte occorre riavviare anche gli fga e il router che hanno alimentazione esterna.

Domanda da lettore incuriosito senza essere minatore: perché volete aggiungere dell'hardware (e quindi un consumo di materia e di energia, oltre che di denaro per l'acquisto e di tempo per l'assemblaggio) quando un watchdog hardware (che è ciò che volete ottenere) è già integrato nel Raspberry Pi? (vedansi risposte di bersani)


Ciao!

Il mio Raspberry pi se non fosse per la corrente che ognitanto va via con i temporali tira da più di due mesi i miei Lancelot senza il minimo problema, basta metterlo in verticale per raffreddare anche "il lato b".

Anche il mio rig con le 5850 girava h24 (tutto il mese di aprile) poi per tenere bassa la botta l'ho programmato per minare solo dalle 19 alle 7. Comunque ho speso altri 100 euro solo di dissipatori "da overclock", in modo da tenere le ventole basse (ne beneficia anche il deposito di polvere)

Yo !

Vedo già un possibile progetto su kickstarter.
"bitcoin hardware watchdog"
Un piccolo hardware specializzato solo per il mining, script più arduino.
Secondo me avresti tanti acquirenti quanti minatori GPU


Piuttosto, domanda en passant.
Su linux c'è un watchdog software che riavvia il pc quando una scheda è sick?

In alternativa, ogni quando impostate un reboot automatico per ovviare a problemi tipo crash dei driver che su linux sto notando sono un po' instabili?

Io pensavo "per sicurezza" ogni sei ore, così da far riposare anche le schede per qualche secondo (cgminer nn prevede pause programmate sfortunatamente).
Ma forse 6 ore sono pochine, 12? 24? una sett?
Ho letto di qualcuno che lo lascia acceso 24/7 anche per un mese... cosa che mi sconvolge assai.

Ragazzi discussione interessante, se io metto il codice per il relè e la LAN di un Arduino, qualcuno ha voglia di mettere insieme uno script che esegue shutdown + stacco del relè per fare il reboot?

Posso scrivere tranquillamente una guida per gestire la parte hardware (saldature, ponticelli, cose da comprare ecc)

Risolto
Svolgo tutti i passaggi così torna utile anche a qualcun altro in futuro.
Allora:
E così sono a posto nel caso di eventuali crash del sistema.
Avvio al boot, nessun ping visto che il watchdog fa casino quando si tratta di controllare la connessione internet.

Poi, scopiazzando un po' qua e la e imparando ad usare crontab:



salvare, uscire, rendere eseguibile


Salvare e uscire.
Ogni 3 minuti controlla l'ip del dns di google e se non è pingabile, riavvia.
usando eth0 funziona per qualsiasi connessione, sia wlan0 che la chiavetta internet 3g.
Ho messo ogni tre minuti perché il riavvio avviene in un possibile arco di tempo x2.
Se la connessione cade proprio dopo il primo controllo, devono passare 3 minuti prima che controlli di nuovo e poi altri tre minuti perché confermi il down e inizializzi il riavvio.

Nel mio caso volevo proprio il riavvio perché, quando muore la chiavetta, hamachi anche se ritorna la connessione non torna UP.


Grazie a tutti!

Lancialo prima a mano prima di configurarlo in crontab. Anzi lo farei controllare ogni 5 minuti invece di ogni minuto, perchè il crontab parte sicuramente prima della tua connessione eheh


FaSan

Allora... non testato ma dovrebbe andare...

prima di tutto lanci un "ifconfig" con la connessione attiva, e vedi il nome dell' interfaccia 3G creata (per esempio 3G-PPP), poi lanci un lsusb per identificare il device della chiavetta (ipotizziamo 1.3.5), configura lo script :


#!/bin/bash
t1=$(ifconfig | grep -o 3G-PPP)
t2='3G-PPP'

if [ "$t1" = "$t2" ]; then
  exit
else
  echo suspend > /sys/bus/usb/devices/1-3.5/power/level
  sleep 2
  echo on > /sys/bus/usb/devices/1-3.5/power/level
  sleep 2
  ifup 3G-PPP
fi

exit


salva in /root/check3g.sh, poi in crontab così :

*/1 * * * * root /root/check3g.sh



Facci sapere ;-)




FaSan

Lo sospettavo.


Si, stessa cosa capita anche a me. Forse le chiavette non sono fatte per continuare a funzionare interrottamente. Poi ogni tanto l'operatore 3 riavvia la rete (di solito a notte fonda) e li salta la connessione.


Aspé, vuoi ridere?
Ho cercato di settare in modo permanente la time zone e il cambio d'ora... e ho fallito più e più volte.
Prima di scoprire che non basta settarla, bisogna anche dare il comando per scriverla nel cmos...
Non mi pare proprio semplice

FaSan, se condividi anche tu i dettagli dello script, magari mixandoli risolvo
In ogni caso ringrazio entrambi

In effetti è più semplice. Piccolo script lanciato da crontab, con verifica ogni minuto.

Dovrei avere da qualche parte... muble muble.. un piccolo applicativo che spegne fisicamente la porta USB e la riaccende. Te lo trovo e te lo mando.




FaSan

Linux non è affatto complicato, anzi è molto semplice.. questo non significa che sia facile
Certo è che tutte le cose che in Linux ti sembrano difficili, su altri OS nemmeno le puoi fare o comunque non con lo stesso livello di personalizzazione+sicurezza.

Per quanto riguarda il blocco del modem anche a me capitava (modem 3g) che si disconnettesse (e non sembrava esserci modo di riconnetterlo senza riavviare), ho risolto con uno script che ogni minuto controllava se c'era internet o meno e in caso negativo, tramite uno script che faceva delle apposite chiamate al kernel, emulava la disconnessione/riconnessione fisica del modem che tornava poi ad essere funzionale (e quindi poi lo riconnetteva a internet).

Mah direi che non serve. RC.LOCAL è l' ultimo ad essere eseguito. Quindi anche con RC3.d non risolvi.

Non c'è un parametro di delay direttamente dentro la configurazione watchdog ?

A boh.
Ho configurato la chiavetta, inserito i parametri di connessione, settato disponibile per tutti gli utenti e "connetti automaticamente".
Impostazione di base di network manager.

All'avvio, appena compare il desktop dopo qualche secondo la chiavetta si logga e la connessione diventa disponibile.
Il reboot con il watchdog avviene "ore prima" che si presenti il desktop.
Non ci arrivo nemmeno a vederlo il desktop

Ho idea che anche rc3.d lavori troppo d'anticipo ma ora provo cmq.

Sarebbe utile a questo punto sapere come lanci la connessione. Hai parlato di una chiavetta 3G quindi dovrebbe esserci un demone PPPd

Ok, questo non funziona (sto provando su debian)
Disabilitato il watchdog al boot.
Aggiunto il watchdog al rc.local secondo la tua linea ma non succede nulla (nel mio file cmq non era presente touch, ma exit 0 e basta).
Se avvio il watchdog a mano dal terminale e la connessione non è attiva, il reboot avviene correttamente

Proviamo un po' quella cosa dei link rc3.d

EDIT:
cambiando la linea in rc.local da
a

Il pc torna in un loop di reboot infinito.
Suppongo che quindi il watchdog parta, ma anche stavolta troppo presto rispetto allo stabilirsi della connessione internet.

Per rc.local ti basta mettere, prima del "touch" il comando da lanciare (per esempio) :

#!/bin/sh
#
# This script will be executed *after* all the other init scripts.
# You can put your own initialization stuff in here if you don't
# want to do the full Sys V style init stuff.

/etc/init.d/watchdog start

touch /var/lock/subsys/local





FaSan

Un giorno qualcuno dovrà spiegarmi perché con linux è sempre tutto così complicato
Cmq vado a spulciare i link rc3.d
Nel frattempo puoi darmi qualche info in più su come lanciarlo da rc.local?
Anche un link va benissimo
Mi tengo una possibilità aperta prima di fare casino con rc3.d


Teamviewer "devo" lanciarlo con 120 secondi di ritardo rispetto all'avvio del sistema, perché altrimenti tutte le connessioni in entrata si freezzano.
Pensavo di cavarmela aggiungendo lo watchdog allo stesso script, ma era pia illusione

Altra cosa importante da dire è che non vengono eseguiti in background ma in ordine. Mettendo quindi un delay nello script non risolvi nulla se non rallentare la macchina nella fase di startup.




FaSan

esempio di link simbolici in rc3.d :


lrwxrwxrwx 1 root root 16 Mar  8 12:16 K01smartd -> ../init.d/smartd
lrwxrwxrwx 1 root root 16 Mar  8 12:16 K10psacct -> ../init.d/psacct
lrwxrwxrwx 1 root root 19 Mar  8 12:16 K10saslauthd -> ../init.d/saslauthd
lrwxrwxrwx 1 root root 22 Jun 26 11:55 K15htcacheclean -> ../init.d/htcacheclean
lrwxrwxrwx 1 root root 20 Mar  8 12:16 K50netconsole -> ../init.d/netconsole
lrwxrwxrwx 1 root root 15 Jun 26 11:48 K75netfs -> ../init.d/netfs
lrwxrwxrwx 1 root root 17 Mar  8 12:16 K75ntpdate -> ../init.d/ntpdate
lrwxrwxrwx 1 root root 19 Mar  8 12:16 K75quota_nld -> ../init.d/quota_nld
lrwxrwxrwx 1 root root 15 Jul  4 23:52 K86cgred -> ../init.d/cgred
lrwxrwxrwx 1 root root 21 Mar  8 12:16 K87restorecond -> ../init.d/restorecond
lrwxrwxrwx 1 root root 15 Jun 26 11:39 K89rdisc -> ../init.d/rdisc
lrwxrwxrwx 1 root root 19 Jul  8 01:30 K92ip6tables -> ../init.d/ip6tables
lrwxrwxrwx 1 root root 18 Jul  4 23:52 K95cgconfig -> ../init.d/cgconfig
lrwxrwxrwx 1 root root 22 Mar  8 12:16 S02lvm2-monitor -> ../init.d/lvm2-monitor
lrwxrwxrwx 1 root root 18 Jun 26 12:10 S08iptables -> ../init.d/iptables
lrwxrwxrwx 1 root root 17 Jun 26 11:39 S10network -> ../init.d/network
lrwxrwxrwx 1 root root 16 Mar  8 12:16 S11auditd -> ../init.d/auditd
lrwxrwxrwx 1 root root 21 Mar  8 12:16 S11portreserve -> ../init.d/portreserve
lrwxrwxrwx 1 root root 17 Mar  8 12:16 S12rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 20 Mar  8 12:16 S13irqbalance -> ../init.d/irqbalance
lrwxrwxrwx 1 root root 19 Mar  8 12:16 S15mdmonitor -> ../init.d/mdmonitor
lrwxrwxrwx 1 root root 20 Mar  8 12:16 S22messagebus -> ../init.d/messagebus
lrwxrwxrwx 1 root root 26 Mar 11 11:11 S25blk-availability -> ../init.d/blk-availability
lrwxrwxrwx 1 root root 19 Mar  8 12:16 S26udev-post -> ../init.d/udev-post
lrwxrwxrwx 1 root root 14 Mar  8 12:16 S55sshd -> ../init.d/sshd
lrwxrwxrwx 1 root root 16 Jun 26 12:10 S64mysqld -> ../init.d/mysqld
lrwxrwxrwx 1 root root 17 Jul  7 22:42 S79bitcoin -> ../init.d/bitcoin
lrwxrwxrwx 1 root root 17 Jul 10 00:00 S80postfix -> ../init.d/postfix
lrwxrwxrwx 1 root root 17 Jun 26 12:10 S80proftpd -> ../init.d/proftpd
lrwxrwxrwx 1 root root 15 Jun 26 12:10 S85httpd -> ../init.d/httpd
lrwxrwxrwx 1 root root 15 Mar  8 12:16 S90crond -> ../init.d/crond
lrwxrwxrwx 1 root root 13 Mar  8 12:16 S95atd -> ../init.d/atd
lrwxrwxrwx 1 root root 11 Jun 26 11:39 S99local -> ../rc.local



I "K" sono i demoni disabilitati, la "S" quelli abilitati, nel mio caso il Network è a S10, e per esempio SSHD a S55. Se fosse stato a S09 per esempio sarebbe partito prima del network, con conseguente errore.

Come vedi a S99 c'è rc.local




FaSan

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