[risolto] Watchdog su linux rig, consigli?

[pink]

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

[bertani]

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

lol la discussione che hai linkato è ridicola..

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

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.

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

windows: teamviewer e simili, linux: ssh

[ziomik]

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

Code:

if ps x |grep -v grep |grep -c quellochevuoi >/dev/null
then
echo "mining... ok"
echo && date >> /var/log/mining.ok
else
echo "mining... restarting"
fi

[bertani]

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

Code:

if ps x |grep -v grep |grep -c quellochevuoi >/dev/null
then
echo "mining... ok"
echo && date >> /var/log/mining.ok
else
echo "mining... restarting"
fi

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:

Q: Cgminer stops mining (or my GPUs go DEAD) and I can't close it?
A: Once the driver has crashed, there is no way for cgminer to close cleanly.
You will have to kill it, and depending on how corrupted your driver state
has gotten, you may even need to reboot. Windows is known to reset drivers
when they fail and cgminer will be stuck trying to use the old driver instance.
GPUs going SICK or DEAD is a sign of overclocking too much, overheating,
driver or hardware instability.

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 

[gdassori]

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.

[bertani]

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

[ziomik]

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.

[FaSan]

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

[bertani]

Me scusi.. ostia... 

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

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

[FaSan]

Me scusi.. ostia...  

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

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

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  )

[bertani]

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  )

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)

[gdassori]

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.

[FaSan]

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  )

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)

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.

[bertani]

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.

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)

[FaSan]

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.

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)

Mi sembra improbabile, ma lo possiamo sempre verificare 

[pink]

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:

Code:

#!/bin/bash

sleep 120
teamviewer &
watchdog &

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

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

windows: teamviewer e simili, linux: ssh

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.

[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.

[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

[FaSan]

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

[pink]

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.

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

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.

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