Newsgroup: it.comp.os.linux.sys
Titolo: problemi con Tar e Cron

Salve, e' il mio primo post, e spero di non cappellare :)
Scenario: ho un server linux - redhat 8 - da un cliente a roma (io sono a 
torino), che fa il backup ogni notte alle 4. Il backup viene effettuato 
con uno script attivato mediante cron, con tar. Ve lo posto qua sotto per 
completezza.
Da un mese a questa parte... il tar ha deciso di non partire piu', cioe' 
lo script viene eseguito fino al tar e li si blocca, non scrivendo 
nemmeno l'errore (eventuale, se c'e').
stranezza 2: se lancio lo stesso script manualmente, funziona senza 
problemi.
Stranezza 3: se lancio lo script mediante at, parte all'ora stabilita.  
Avete qualche idea ? O_O Io non so che pesci pigliare...
ecco il cron.daily
lrwxrwxrwx    1 root     root           28 apr 28  2003 00-logwatch -> 
../log.d/scripts/
logwatch.pl
-rwxr-xr-x    1 root     root          276 ago 28  2002 0anacron
-rwxr-xr-x    1 root     root          600 nov 21 11:22 backup
-rwxr-xr-x    1 root     root           51 giu 23  2002 logrotate
-rwxr-xr-x    1 root     root          418 apr  2  2003 makewhatis.cron
-rwxr-xr-x    1 root     root          104 set  4  2002 rpm
-rwxr-xr-x    1 root     root          132 giu 24  2002 slocate.cron
-rwxr-xr-x    1 root     root          193 giu 24  2002 tmpwatch
ed ecco lo script
#!/bin/bash
cd /
echo "----------------------" >> /var/log/backup
echo "Arresto samba" >> /var/log/backup
#/etc/rc.d/init.d/smb stop
echo "Backup avviato alle" >> /var/log/backup
date >> /var/log/backup
tar zcvf /dev/st0 dati/documenti dati/varie home/ --label "backup 
automatico" 2>> /var/log/backup_registry
echo "Backup terminato alle" >> /var/log/backup
date >> /var/log/backup
echo "Riavvio samba" >> /var/log/backup
#/etc/rc.d/init.d/smb start
echo "----------------------" >> /var/log/backup
ed infine ecco come appare il log:
----------------------
Arresto samba
Backup avviato alle
Tue Dec  2 04:02:03 CET 2003
Ecco invece un log completo impostato con At all'1.00
------TEST fatto da gareth----------
Arresto samba
Backup avviato alle
mar dic  2 01:00:00 CET 2003
Backup terminato alle
mar dic  2 01:12:06 CET 2003
Riavvio samba
----------------------
Idee? :(
-- 
Gareth Jax
Ihgger #7*3*2
Indegno Neurone della Mente alveare
Big Bad of Con-Fu Fighting
avvistatore su ihgg di Vincenzo Beretta

 
Sparo a caso....
1) E' impostato un reboot della macchina dopo le 4.00.
2) Quando fai le prove a mano o con at salvi le stesse directory ?
   Se no, allora forse hai riempito il nastro e si ferma a chiedere
   il secondo volume.
3) Errori fisici o altre strane cose fanno si che il tar si fermi
   in input da tastiera.
4) Qualche processo locca un file in modo esclusivo.
Dopo >> /var/log/backup aggiungi 2>&1 e vedi se nei log ti scrive
qulcosa in piu'.
Hai guardato il syslog ?
Se ne ho azzeccata una cosa vinco ?  :)
-- 
Stefano L.

 Avete qualche idea ?
per curiosità guarda che processi ti rimangono attivi quando trovi il tuo
log incompleto... magari ti può dare qualche indicazione in più sapere che
tar è ancora in esecuzione..
non so poi se è influente ma come path del source nel comando tar prova a
partire da / ..quindi (es.):
tar -zcvf /dev/st0 /dati/documenti /dati/varie home/  ecc...
non saprei che altro dirti!
ciao!

 Se ne ho azzeccata una cosa vinco ?  :)
Un posto in paradiso se sei credente, una birra alla prima occasione 
possibile se sei ateo :)


 tar -zcvf /dev/st0 /dati/documenti /dati/varie home/  ecc...
il fatto e' che lanciando quello stesso script da shell, funziona 
perfettamente :-/


Ciao Gareth,
  io ti suggerisco di fare qualche modifica allo script per
avere qualche informazione extra (ed uno script piu'
leggibile ;-) ).
Il log. Leva via tutti i ">>/var/log/backup" e metti un
re-indirizzamento globale:
#!/bin/bash
(
..
.. lo script senza tutti quei  >>/var/log/backup
..
) >>/var/log/backup 2>&1
Questo di mandera` tutti gli output sul file di log senza dover
ogni volta fare ">>". Inoltre mandera` anche lo standard error
sullo stesso file.
Poi puoi mettere "set -x" come prima istruzione (prima di "cd /").
Questo ti fara` il log dei comandi come sono eseguiti.
Occhio che SAMBA non viene mai fermato/riavviato (linee commentate)
La data puoi scriverla come
echo "Backup avviato alle `date`"
questo ti fara` l'output su una linea sola...
Altrimenti non so dove possa essere il problema. Metti il
"set -x" e guarda che ti dice. "at" e "cron" di solito sono
interscambiabili. L'utente delle due prove e` lo stesso?
Ciao,
-- 
       Roberto Divia`             Love at first sight is one of the greatest
       =============             labour-saving devices the world has ever seen.
Mailbox: C02110                 CERN-European Organization for Nuclear Research
E-mail: 
Robert...@cern.ch
           CH-1211 GENEVE 23, Switzerland

 interscambiabili. L'utente delle due prove e` lo stesso?
sempre root. :(
Boh, stanotte vediamo e domani riferisco :)
per ora grazie


 perfettamente :-/
si, ma devi pensare che cron e at non sono la shell e (IMHO) più
specifichi e meno probabilità di errore ci sono...
ciao!

 perchč se rimane appeso tar lo devi tirar giů a manina...
Apparentemente il backup e' stato fatto, ma nel backup non e' stato 
loggato nulla :( la dimensione del file e' zero.
Ecco i processi presenti a stamattina.
[root@magister root]# ps -efa
UID        PID  PPID  C STIME TTY          TIME CMD
root         1     0  0 Dec01 ?        00:00:04 init
root         2     1  0 Dec01 ?        00:00:00 [keventd]
root         3     1  0 Dec01 ?        00:00:00 [ksoftirqd_CPU0]
root         4     1  0 Dec01 ?        00:00:00 [kswapd]
root         5     1  0 Dec01 ?        00:00:00 [bdflush]
root         6     1  0 Dec01 ?        00:00:00 [kupdated]
root         7     1  0 Dec01 ?        00:00:00 [mdrecoveryd]
root        15     1  0 Dec01 ?        00:00:00 [kjournald]
root        71     1  0 Dec01 ?        00:00:00 [khubd]
root       152     1  0 Dec01 ?        00:00:00 [kjournald]
root       461     1  0 Dec01 ?        00:00:00 syslogd -m 0
root       465     1  0 Dec01 ?        00:00:00 klogd -x
rpc        482     1  0 Dec01 ?        00:00:00 portmap
rpcuser    501     1  0 Dec01 ?        00:00:00 rpc.statd
root       531     1  0 Dec01 ?        00:00:00 /sbin/apcupsd -f 
/etc/apcupsd/ap
root       610     1  0 Dec01 ?        00:00:00 /usr/sbin/sshd
root       625     1  0 Dec01 ?        00:00:00 xinetd -stayalive -
pidfile /var/
root       634     1  0 Dec01 ?        00:00:00 crond
root       643     1  0 Dec01 ?        00:00:00 smbd -D
root       647     1  0 Dec01 ?        00:00:02 nmbd -D
daemon     665     1  0 Dec01 ?        00:00:00 /usr/sbin/atd
root       677     1  0 Dec01 ?        00:00:00 rhnsd --interval 120
root       688     1  0 Dec01 tty1     00:00:00 /sbin/mingetty tty1
root       689     1  0 Dec01 tty2     00:00:00 /sbin/mingetty tty2
root       690     1  0 Dec01 tty3     00:00:00 /sbin/mingetty tty3
root       691     1  0 Dec01 tty4     00:00:00 /sbin/mingetty tty4
root       692     1  0 Dec01 tty5     00:00:00 /sbin/mingetty tty5
root       693     1  0 Dec01 tty6     00:00:00 /sbin/mingetty tty6
root      2352   643  0 10:03 ?        00:00:00 smbd -D
root      2353   610  0 10:04 ?        00:00:00 /usr/sbin/sshd
root      2355  2353  0 10:04 pts/0    00:00:00 -bash
root      2403  2355  0 10:06 pts/0    00:00:00 ps -efa


 sullo stesso file.
ehmmm... ha sovrascritto il /log/backup :)
non e' che ci voleva 2>>&1 ? :)


 non e' che ci voleva 2>>&1 ? :)
Gareth! Vecchio lupo sabaudo!
Pure qua in lande linuxare?
-- 
Renato Ramonda (aka Morpheus, IHGGer #904)
_______________________________
Togli TOGLIMI se vuoi scrivermi

 Pure qua in lande linuxare?
Sai com'e', per lavoro si impara a usare un po' di tutto, senza farsi 
troppe paranoie :)


 loggato nulla :( la dimensione del file e' zero.
Come hai corretto lo script ?
Hai controllato se c'e' altro nel crontab che potrebbe dare
fastidio alla copia ?
Prova ad aggiungere mt -f tuo_device_nastro status prima e dopo il comando
tar nello script.
-- 
Stefano L.

 non e' che ci voleva 2>>&1 ? :)
No
-- 
Stefano L.

 troppe paranoie :)
Dillo a me... per lavoro faccio piu' che altro assistenza su win! ^__^
-- 
Renato Ramonda


 fastidio alla copia ?
a tutti gli effetti lo script ha funzionato, perche' l'at che avevo messo 
al fondo dello script e' stato eseguito correttamente e infatti lo vedo in 
coda con atq.
La parte misteriosa e' l'azzeramento di /var/log/backup :)
Devo portarlo al LLUG ? (linux Lourdes User group) :)


 La parte misteriosa e' l'azzeramento di /var/log/backup :)
Sicuro che modificando non hai messo un > invece di >> ?
-- 
Stefano L.


*LOL*      ^__^
bye G.L.

 non e' che ci voleva 2>>&1 ? :)
Per il tuo problema, prova a invocare lo script di backup da UN'ALTRO 
script e recupera la variabile d'uscita
ad esempio
--------------8<-----taglia qui---------8<----------
#!/bin/bash
# Stupido lanciatore
/usr/local/backupscript.sh
if [ $? == 0 ];
then
     echo "Sembra tutto ok" >> /home/pippo/controllo
else
     echo "Terminato con errore" >> /home/pippo/controllo
fi
--------------8<-----taglia qui---------8<----------
cosi' almeno sai se il dannato script di backup termina con errore o 
scompare del tutto...


 ? :#)
2>&1 manda lo standard error sullo standard output (nel tuo caso in 
/var/log/backup)
Sparo a caso anch'io:
L'utente con cui lanci lo script a mano è lo stesso del crontab? 
Immagino di si, ma se non lo fosse prova a guardare i permessi dei file 
di cui cerchi di fare il backup
-- 
Ciao
Morsac

 Sicuro che modificando non hai messo un > invece di >> ?
copiato ed incollato...


 --------------8<-----taglia qui---------8<----------
Provo, ma dannazione fino ad un mese fa funzionava come un cronografo 
svizzero...


 svizzero...
Raggi cosmici?
Ha fallito il tiro salvezza su "Sfighe inspiegabili"? ;-P


 non e' che ci voleva 2>>&1 ? :)
No.
Per appendere:      >>/var/log/backup
Per sovrascrivere:  >/var/log/backup
2>&1 server per ri-assegnare lo stream 2 (stderr) sullo stream 1 (stdout).
Lo stream 0 e` lo stdin. Se non metti 2>&1 allora i messaggi di stderr
vanno su uno stream diverso (terminale o - nel caso di job lanciati con
cron/at/batch - via mail all'account chiamante). Mettendo 2>&1 i due
stream diventano uno e hai tutti i messaggi, di errore e di output, sul
file di log.


 output, sul file di log.
Strepitoso... ma era a dimensione zero...


Tutto mi fa pensare che sia il tar che si blocca e di conseguenza non chiude
il file di log avendo modificato con
(
.
.
.
) >> ........
Io riproverei a mettere >> /var/log/backup 2>&1 su ogni riga
Sulla riga del tar, invece metterei tanto per provare
tar zcvf /dev/st0 dati/documenti dati/varie home >> /var/log/backup.elenco
2>> /var/log/backup
oppure
tar zcf /dev/st0 dati/documenti dati/varie home >> /var/log/backup 2>&1
Magari metti anche un ps -ef >> /var/log/pippo 2>&1 subito prima del tar
-- 
Stefano L.

 La parte misteriosa e' l'azzeramento di /var/log/backup :)
Questo puo` succedere se hai due processi, uno che scrive e uno che
cancella un file (o uno che sovrascrive).
Qualche suggerimento extra:
1) usa "{" e "}" invece di "(" e ")": non creera` un secondo processo,
nel caso che non gli piaccia;
2) il --label su due linee e` normale?
3) invece di /bin/bash potresti provare con /bin/sh (piu' veloce ma meno
features...);
4) che fa la linea "at -f /etc/cron.daily/backup 1amtomorrow"? Schedula
la stessa procedura per il giorno dopo? In quel caso potresti avere due (o piu')
job schedulati e questo non e` bbuono (fai "at -l" come root e vedrai quanti
job hai in coda);
5) se "at -f ..." e` come penso, allora potresti fare "at -f $0 1amtomorrow".
Piu' elegante...


 come root e vedrai quanti job hai in coda);
mi serviva per vedere se lo script veniva eseguito fino in fondo. Il cron 
parte alle 4 di mattina: in realta' l'orario che ho messo (l'una del 
giorno dopo) e' puramente indicativo.
Diciamo che anche in mancanza di log, mi e' servito per capire che lo 
script e' stato eseguito fino in fondo, perche' l'at era l'ultima 
istruzione, e stamattina l'at era stato messo in coda.
Per questo ritengo con una certa ragionevolezza, che lo script cosi' 
com'e' abbia funzionato! :) (stdout escluso)


 tar 
Inserito :)
Speriamo in bene... Sono comunque gia' contento che il backup sia ripreso, 
ora vediamo di far saltare fuori anche i log :)


 ) >> /var/log/backup 2>&1
ciao Gareth, ti rispondo anche io :-)
Prima di tutto, giusto per finezza, invece di redirigere sulle singole
righe, oppure utilizzando le parentesi intorno a tutto, basta che
all'inizio dello script, dopo la riga #!/bin/bash, tu aggiunga la riga
exec >> /var/log/backup 2>&1
questo fa si' che lo standard input e lo standard error del processo in
corso vengano rediretti sul file specificato
secondo, sempre per finezza, la riga
echo "Backup avviato alle `date`"
puo' essere riscritta, ad esempio, come
date +"Backup avviato alle %c"
oppure come
date +"Backup avviato alle %X del %x"
Inoltre, dai tuoi post non mi e' chiaro se il backup abbia funzionato o
no, in uno dici che l'ha fatto, nell'altro dici che sembra che l'abbia
fatto vuoto.
Non ho anche capito se la riga del tar e' spezzata in due (-- label
"backup [a capo] automatico") come ce l'hai postata qui, oppure se e'
tutta intera. Nel primo caso io toglierei di sicuro il linebreak.
Prova anche a controllare la mail di root, se gia' non l'hai fatto: il
cron spedisce una mail a root se uno dei processi eseguiti ha avuto
qualcosa da dire. Per sicurezza puoi anche guardare in /etc/crontab la
riga MAIL=xxx qual e' l'utente preposto alla ricezione delle mail di
cron (normalmente root).
Se anche nella mail non trovi niente, prova lo script aggiungendo in
coda ad ogni riga:
 2>&1|tee -a /tmp/altrofiledilog
ciao
Guido
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ciao Gareth, ti rispondo anche io :-)
[snip]
oops! sono sempre il solito ^__^;;
non avevo visto l'altro messaggio che diceva "tutto risolto".
Ad ogni modo, i consigli di "finezza" restano validi :-)


 Ad ogni modo, i consigli di "finezza" restano validi :-)
grazie cmq :)
