pink (OP)
|
|
July 16, 2013, 05:08:08 PM Last edit: July 18, 2013, 11:33:26 AM by 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=20149Un 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
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
July 17, 2013, 02:36:51 AM |
|
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.txtPer 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
Legendary
Offline
Activity: 1960
Merit: 1012
SELL bitcoinmarket.net | bitcoinitalia.com SELL
|
|
July 17, 2013, 05:59:59 AM |
|
na cosa così da avviare ogni x con crontab, no ? 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
|
DOMINI IN VENDITA/NOLEGGIO bitcoinmarket.net | bitcoinitalia.com
Contattatemi pure per info. ---- +++ ---- "Se domani senti due massaie che parlano di bitcoin tra di loro dal macellaio, forse e' il momento di vendere.. se pero' le sentirai fra 10 anni forse staranno solo pagando il conto" GBianchi ---- +++ ----
|
|
|
bertani
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
July 17, 2013, 06:16:57 AM |
|
na cosa così da avviare ogni x con crontab, no ? 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
|
|
July 17, 2013, 06:49:01 AM |
|
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
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
July 17, 2013, 06:58:55 AM |
|
Sì Guido, l'alternativa è un relè esterno, solo per i veri duri
|
|
|
|
ziomik
Legendary
Offline
Activity: 1960
Merit: 1012
SELL bitcoinmarket.net | bitcoinitalia.com SELL
|
|
July 17, 2013, 09:45:32 AM |
|
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.
|
DOMINI IN VENDITA/NOLEGGIO bitcoinmarket.net | bitcoinitalia.com
Contattatemi pure per info. ---- +++ ---- "Se domani senti due massaie che parlano di bitcoin tra di loro dal macellaio, forse e' il momento di vendere.. se pero' le sentirai fra 10 anni forse staranno solo pagando il conto" GBianchi ---- +++ ----
|
|
|
FaSan
|
|
July 17, 2013, 09:54:27 AM |
|
Uhmm un Arduino con un relè sul pulsante di reset e un ping (o un telnet) dovrebbe bastare
|
|
|
|
bertani
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
July 17, 2013, 10:05:38 AM |
|
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
|
|
July 17, 2013, 10:15:55 AM |
|
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
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
July 17, 2013, 10:20:14 AM |
|
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
|
|
July 17, 2013, 10:23:12 AM |
|
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
|
|
July 17, 2013, 10:27:50 AM |
|
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
Legendary
Offline
Activity: 1022
Merit: 1000
|
|
July 17, 2013, 10:36:19 AM |
|
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
|
|
July 17, 2013, 10:39:00 AM |
|
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 (OP)
|
|
July 17, 2013, 12:58:10 PM |
|
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: #!/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
|
|
July 17, 2013, 01:29:32 PM |
|
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
|
|
July 17, 2013, 01:32:47 PM |
|
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
|
|
July 17, 2013, 02:14:41 PM |
|
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 (OP)
|
|
July 17, 2013, 02:39:19 PM |
|
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
|
|
|
|
|