Newsgroup: it.comp.os.linux.iniziare
Titolo: interrompere un comando schedulato ad una determinata ora

ho imparato bravo bravino a far eseguire i "compiti pianificati" alla 
mio ubuntu 10.04, ovvero a far partire un comando quando voglio io.
adesso pero' vorrei anche interrompere questo comando quando-voglio-io
Nel concreto, alla mezzanotte ed un minuto inizia un lungo rsync che 
salva i backup in remoto.
Ho la necessita' di interromperlo la mattina successiva, diciamo per le 
7,30 affinche' ci sia banda libera per il normale lavoro d'ufficio.
Idee su come interrompere il comando lanciato?
ciao
gg

 Idee su come interrompere il comando lanciato?
Prova ad usare "at" che lancia uno script che "kill" il pid del
processo (comunicato da "ps") che vuoi chiudere.
-- 
Ciao
Gianluca


Perché at? Non sarà meglio il buon vecchio cron?
#!/bin/bash
PID=$(ps -A | grep rsync)
if [ "$PID" ]; then kill -9 $PID; fi
e lo richiami in /etc/crontab come
30 7 * * * root nomescript.sh
Come estrarre il PID è solo un esempio, lì bisogna vedere come si può
identificare il processo. Comunque la logica è questa, non è che ci
voglia molto.
Piuttosto però... se hai un processo così gravoso, immagino che ci sia
anche un buon motivo di farlo girare. Se lo killi, ottieni una
sincronizzazione parziale e quindi dei dati, probabilmente, inutilizzabili.
Sei sicuro che sia una buona idea?
-- 
Massimo Bacilieri AKA Crononauta

 Idee su come interrompere il comando lanciato?
se ti va bene ammazzare tutti gli rsync in corso alle 7.30, dovrebbe 
bastare una cosa tipo
kill -9 $(pidof rsync)
nel crontab delle 07.30.
Se invece alcuni li vuoi ammazzare, altri no, allora la cosa e' piu' fine.

 
Be', le statistiche su cosa cambia ogni giorno nei suoi archivi le sa
solo lui. ;-)
Io se interrompo i miei backup basandomi sul tempo, mi ritrovo con una
parte dei colleghi cha hanno tutti i backup, e alcuni che non ne hanno
nemmeno un bit salvato.
-- 
           |Save our planet!
    Ciao   |Save wildlife!
   roberto |For your E-MAIL use ONLY recycled Bytes  !!
           |roberto poggi   
rpo...@softhome.net



30 7 * * 1-5 sudo killall rsync
-- 
[cRuncH] - and....yes, we crunch
 
- Se sbagliamo ancora il capo ci ammazza.
- No, non ci ammazza: non e' cosi' buono...
		-- Da "Super Mario Bros"

 Idee su come interrompere il comando lanciato?
l'obiezione di roberto va intesa come:
<don abbondio>Sto backup nun s'ha da interrompe</don abbondio>
prima di pensare a come interrompere un backup:
- anticipare l'inizio dei backup
- verificare cosa rallenta l'esecuzione
- sfrutare anche l'ora del pranzo per quei server pocho carichi
- comprare hardware migliore per l'infrastruttura di backup.
se poi vuoi proprio seguire questa strada:
- pkill -TERM rsync
  (TERM serve a fare una chiusura pulita di tutti i file aperti dal
   processo chi si vuole terminare)
- pgrep rsync
- pkill -KILL rsync
  (con KILL  i file aperti... )
ma cosa molto più importante, scrivi in un bel cartello (6x3m mnimo):
"Se volete che interrompa i backup: FATE UNA RICHIESTA SCRITTA".
non sarai tu quello che imparerà il mestiere dell'ortolano.
ciao
michele

 salva i backup in remoto.
Ma in quell'azienda li lavorano fino alla mezzanotte?
Generalmente tutti staccano alle 17:30, sarebbe strategico far partire 
il backup alle 17:31 in quel caso no?
Poi esiste l'opzione --bwlimit che ti consente di limitare la banda ad 
un tot di kilobyte..

 <don abbondio>Sto backup nun s'ha da interrompe</don abbondio>
Be'. in realtà, non è detto.
Infatti ho parlato di statistiche sulla variabilità dei dati
che debbono far pensare il sysadmin.
L'OP usa rsync (se il mio neurone funziona ancora).
A seconda di come è il suo archivio, e di che cosa fanno gli
utenti sui file da archiviare in modalità differenziale e/o
incrementale, potrebbe anche rischiare, accettando che il backup
non sia affidabile nelle 24 ore, ma che lo sia nelle 48.
Insomma, perdo i miei dati di ieri e non solo quelli di oggi.
Piuttosto che niente, è meglio un tosto.[*]
Ma se le attività degli utenti sono più o meno sempre le stesse,
se si usa solo la funzionalità differenziale di rsync, c'è il
rischio di avere una parte degli utenti i cui dati non vengono
MAI backuppati, visto che li elaborerebbe sempre e comunque in
coda agli altri.
Mi associo al consiglio di migliorare l'infrastruttura di backup,
ci sono svariate cose che si possono attuare per migliorarla.
Oh, pura teoria, potrebbe anche essere che l'OP è già nel migliore
dei casi, e non c'è molto da fare.
Se proprio non si può arrivare ad avere il backup completo ogni giorno
si possono studiare trucchi per farlo comunque nelle 48 ore, ad esempio
memorizzando l'elenco completo dei file da backuppare: comincio a
copiare e memorizzo un flag di "eseguito" man mano che procedo.
Ad un certo punto, stoppo tutto perché gli utenti debbono lavorare.
Domani, accodo i file mancanti alla lista, ma inizio a copiare dai file
che avevo lasciato indietro oggi, riordinando per flag di eseguito.
Così facendo, allargo la fascia di rischio, ma sono sicuro che prima o
poi tutti i file vengono salvati.
No, non so se qualche software di backup lo fa già di suo, ma sarei
ottimista.
[*] Io ho considerato un backup in una realtà simile alla mia, dove ci
sono svariati utenti, ognuno dei quali ha i suoi archivi, oltre agli
archivi globali dell'azienda (gestionale et similia) che comunque hanno
la precedenza nei backup; ovviamente, ogni sysadmin sa, nella SUA realtà
quali dati sono strategici, e quali comportano solo un mugugno in caso
andassero persi.


 if [ "$PID" ]; then kill -9 $PID; fi
  Non capisco questa mania generalizzata di usare sempre e solo il
segnale KILL.  Tutta la manualistica e le guide dell'ABC del bravo
amministratore di sistema dicono invariabilmente che KILL è un segnale
di ultimo ricorso dopo che il TERM non è riuscito, dopo un tempo
ragionevole (da due a cinque secondi), a far terminare un processo.
Usare KILL quando non necessario è pericoloso, può lasciare il sistema
sporco (fd e socket non chiusi correttamente, processi zombie, zone di
memoria allocate non flushate o rimaste nel limbo, semafori o lock
lasciati sparsi qui e la...)
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.


Facebook: Massimo Bacilieri

 non l'ha fatto, quindi...
  Ma che tempo perdi a fare kill -TERM "$PROCESSO" ; sleep 5 ; test -n
"$(ps h -o pid "$PROCESSO")" && kill -KILL "$PROCESSO" invece di kill
-KILL "$PROCESSO" quando il tutto gira in uno script di crontab?
  Prendere le buone abitudini anche quando sembrerebbe inutile farlo ti
può salvare quando inaspettatamente seguire la "teoria" diventa invece
essenziale.


 essenziale.
  Ma soprattutto, il processo in questione (il backup via rsync lanciato
da cron) *non* ha ricevuto nessun segnale ancora.  Tu scrivi che «quando
hai un processo che è ghost, stare a perdere tempo con il "TERM" è
inutile, avrebbe già dovuto fare "TERM" da solo e non l'ha fatto».  Ma
il processo rsync non ha ancora ricevuto nessun TERM né avrebbe dovuto
darselo da solo, se il backup è ancora in corso.  Si sta dando per
scontato che sia un processo bloccato quando non c'è ragione di
ritenerlo tale.  E comunque, anche quando si sospetta che un processo si
sia arenato (su un'operazione non interrompibile di IO che non si
completa, tipicamente), gli si manda prima un TERM, soprattutto se si
sta operando su script non interattivi in circostanze in cui non si può
investigare di persona.  Se non lui, suoi eventuali figli o thread
avranno il tempo di uscire in modo pulito.


 mio ubuntu 10.04, ovvero a far partire un comando quando voglio io.
grazie a tutti per le informazioni!
in settimana faro' delle prove.
ciao
gg
PS: il backup viene fatto settimanalmente tra 2 directory. anche 
interrompendo il processo non perdo o tralascio dati perche' l'rsync il 
giorno successivo riparte e mette a posto il lavoro lasciato a meta' il 
giorno prima.
PS2: e' il backup remoto di un backup locale.
:-)


PS3: il backup giornaliero viene comunque fatto su un server locale.

 PS2: e' il backup remoto di un backup locale.
Be', questo sposta i termini del problema, in effetti.
