Newsgroup: it.comp.os.linux.sys
Titolo: Crontab in HighAvailability

Ciao a tutti!
 
In ufficio abbiamo 4 Servers che, tramite un LoadBalancer, gestiscono
tutto il Web della ditta e dei clienti.
Fin qui, tutto bene...
 
Ora, abbiamo alcuni script che devono girare ad intervalli regolari. E per
quello, ovviamente, c'e' cron.
 
Il problema, pero', e' che se, per esempio, uno script deve girare SOLO
una volta al giorno, non posso farlo lanciare a tutti e quattro i Servers
senza un controllo, in quanto mi verrebbe lanciato 4 volte e non una.
D'altronde non posso neanche configurare cron solo su UN Server, in
quanto, se quello muore, nessuno prenderebbe il suo posto per gestire cron.
 
Ora, prima di mettermi a scrivere un programma apposta che fa il
controllo, sapete se gia' esiste qualcosa che fa al caso mio?
 
Grazie
Luca Bertoncello
(
luca...@lucabert.de
)
 
-- 
 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it
 
 
 

 senza un controllo, in quanto mi verrebbe lanciato 4 volte e non una.
 
Se hai un bilanciatore, hai anche un filesystem condiviso (salvo configurazioni particolari).
Mettici dentro un lockfile che sarà letto da tutti e 4 i crontab.
 
Al limite, simula una sorta di lockfile tramite database.

 Mettici dentro un lockfile che sarà letto da tutti e 4 i crontab.
 
Ovviamente ho un filesystem condiviso. E anche l'idea che avevo avuto era
del Lock-file, che pero' dev'essere cancellato da qualcuno per permettere,
diciamo il giorno dopo, di far partire nuovamente lo script.
 
La mia domanda era se esistono programmi gia' pronti che risolvano il
problema o se devo scrivermi qualcosa io...
 
Ciao


 diciamo il giorno dopo, di far partire nuovamente lo script.
 
Ed il problema quale sarebbe?
 
if ! [ -f lockfile ]; then touch lockfile && crontab && rm lockfile; fi;

 Il giorno gioved� 20 settembre 2012 17:38:16 UTC+2, Luca Bertoncello ha

Il problema sarebbe che, cosi' facendo, visto che gli script vengono
eseguiti in pochissimo tempo (millisecondi, per lo piu'), lo script
verrebbe probabilmente eseguito su piu' nodi...
No, la cancellazione dev'essere fatta in un secondo tempo.
 
Se non esiste niente di gia' pronto faro' uno script che, se il Lockfile
esiste, ne controlla l'eta' e, SOLO SE e' "abbastanza vecchio", lancia lo
script.



 
Potresti scrivere un piccolo script di risorsa LSB da associare ad un 
singolo Nodo del cluster, quindi verrebbe eseguito solo da quello,
se muore migrer� sul primo nodo disponibile.
 
-- Yena --
 

 se muore migrer� sul primo nodo disponibile.
 
Sarebbe un'idea, ma il Cluster non e' gestito da noi, purtroppo...
Devo parlarne con il provider...
 
Grazie


 verrebbe probabilmente eseguito su piu' nodi...
 
Non puoi ritardare le esecuzione di un secondo su ciascun nodo?
Esempio: cron1 alle 00:00:00, cron2 alle 00:00:01, cron3 alle 00:00:02, cron4 alle 00:00:04
 
oppure ritardarle di un tempo random da 0 a X secondi.

 Il giorno gioved� 20 settembre 2012 17:54:11 UTC+2, Luca Bertoncello ha

Da quando posso definire i secondi nella crontab?


 Da quando posso definire i secondi nella crontab?
 
da sempre:
 
/bin/sleep 1 && script

 diciamo il giorno dopo, di far partire nuovamente lo script.
 
 
Perché deve essere cancellato da qualcuno? Il computer non esiste 
proprio per fare il lavoro sporco?
 
1° job
 
if test -a $lockfile
  then
    exit 1
  else
     touch $lockfile
     do_cronjob
fi
 
 
dodici ore dopo:
 
2° job
 
 
if test -e $lockfile
  then
    rm-f $lockfile
 
 
Oppure:
 
if test -a $lockfile
  then
    exit 1
  else
     touch $lockfile
     do_cronjob
     sleep 1 hour
     rm -f $lockfile
fi
 
 
Comunque l'idea di aspettare un certo tempo casuale prima di fare
il lavoro non è malvagia