Newsgroup: it.comp.os.linux.sys
Titolo: cron job variabile

Salve a tutti,
 
riguardo il discorso di qualche tempo fa sul watchdog
di un sito web, ho adottato la soluzione "curl".
 
Ora, pero`, ho, forse, un non problema.
 
Vorrei fare il check, diciamo, ogni 60 minuti.
 
In caso tutto sia OK, check successivo in 60 minuti,
altrimenti restart / mail / quello che e`, check
successivo dopo *5* minuti.
 
L'idea sarebbe di non aspettare un'altra ora prima
di verificare di nuovo che tutto funzioni.
 
Non so se questa cosa abbia proprio senso, ma al
momento mi pareva una buona idea.
 
Ora, cron esegue processi, in caso si usi, per esempio,
/etc/cron.hourly, ogni ora, fisso.
 
Per risolvere ho fatto uno script, alla cui fine c'e`
qualcosa come "at now +$T_OUT min < this_script.sh", dove
T_OUT puo` esser 60 o 5, dipende dal risultato del check.
 
Adesso, questa cosa funziona, ma non e` affidabile, dato
che, in caso di problemi o reboot *durante* l'esecuzione
dello script, questo non verra` riavviato, mancando il
comando "at" eseguito alla fine.
 
Lunga spiegazione per chiedere:
 
1) ha senso fare i check ad intervalli diversi, in funzione
del risultato precedente?
2) esiste un metodo migliore?
3) in generale, esiste un metodo per eseguire qualcosa tot
tempo *dopo* che ha finito e non ogni tot minuti?
 
Grazie anticipatamente,
 
bye,
 
-- 
 
piergiorgio

 tempo *dopo* che ha finito e non ogni tot minuti?
 
Io per una cosa analoga (check ogni 30 minuti ed in caso di allarme ogni 
60 secondi) ho usato uno script che entra in loop se vi è allarme e 
ripete il test ogni minuto fino a che non rientra.
 
Per evitare che successive schedulazioni vadano ad interferire lo script 
mette un lock che rimuove all'uscita.  Se all'avvio trova il lock esce 
immediatamente.
 
Può sembrare esagerato fare tanto lavoro, ma anche se crond potrebbe (?) 
fare il lavoro non ho capito il suo funzionamento.  E poi non tutte le 
distribuzioni hanno lo stesso crond.
 
Ciao
Giovanni
-- 
   A computer is like an air conditioner,
   it stops working when you open Windows.
   < 
http://giovanni.homelinux.net/
 >

 che ha finito e non ogni tot minuti?
 
uno script che in uscita richiama se stesso con "at piu' xx minuti" 
potrebbe andar bene? 
 
ma onestamente , che ti importa? L'alert, mail, se tutto va bene lo 
vedrai comunque con mezz'ora di ritardo :) Non so se vale veramente la 
pena andare cosi' di fino e per il sottile :) 
 
-- 
Massimiliano Adamo

 successivo dopo *5* minuti.
 
Io per aggiornare l'ip dinamico ho uno script avviato da cron ad intervalli.
Nello script, verifico se l'ip è cambiato, in tal caso aggiorno.
Poi, dopo 30 secondi (un banale sleep) verifico che sia aggiornato il dns.
Se ok esco dallo script, altrimenti rifaccio l'aggiornamento e ricontrollo dopo 30*2 secondi.
Ripeto per 3 volte conme sopra, aumentando l'intervallo, sempre usando sleep.
Se non avviene aggiornamento, mail a root ed uscita.
 
Nel mio caso, non mi interessa una grande precisione dei tempi...
 
-- 
The future is wonderful, the future is terrifying.
The future? But will we still be there?

del risultato precedente?
 
Sì. Io faccio così, e anzi pure le mail le mando in funzione di quando ho
mandato quella prima. Per es:
 
	02:00 ALERT (P=1H, G=4H) on trigger PING-VDSL-PIPPO
	06:00 ALERT (P=5M, G=4H) on trigger PING-VDSL-PIPPO
	07:25 CONDITION NORMAL (P=5M, G=30M) on trigger PING-VDSL-PIPPO
 
...significa:
 
	alle 02:00 un test con periodicità oraria è fallito
	Ha continuato a fallire ogni 5 minuti fino alle 07:25
	Ha dato esito favorevole ogni 5 minuti fino alle 07:55 (*)
	Alle 07:55 siamo ritornati alla periodicità oraria.
 
Leonardo
 
(*) perché non mi fido necessariamente del primo "tutto bene"
-- 
 
"You all presumably know why" :-) :-(

 ho mandato quella prima. Per es:
 
 
OK. In questo modo catturi il momento in cui il servizio e' stato 
ripristinato. 
Per esempio io, solo con DRBD (solo fin quando non lo avro' tolto di 
mezzo per sempre), invio messaggi su un canale Slack. 
 
Problema: il canale e' condiviso, e non posso inviare messaggi uno dopo 
l'altro fin quando il problema non e' rientrato.  
 
Cosa faccio? Ho un check che gira ogni minuto. 
 
Se succede qualcosa, manda un messaggio su Slack e crea un semaforo sul 
filesystem. 
Il giro successivo, se il servizio ancora non funziona, e se c'e' il 
semaforo, non fa niente. 
Il giro successivo, se il servizio e' stato ripristinato, se c'e' il 
semaforo, lo cancella e invia un messaggio di avvenuto ripristino su 
Slack. Se non c'e' il semaforo, vuol dire che tutto va bene e che andava 
bene pure prima e non fa niente. 
 
Ottengo ZERO spam e capisco con precisione sufficiente quando il servizio 
e' stato ripristinato. 
 
Alla stessa maniera.... qualora ci fosse il semaforo, potrei lanciare il 
check ad un ritmo piu' intensificato usando "at" dal check stesso (non lo 
faccio perche' non mi interessa). 
 
-- 
Massimiliano Adamo