Newsgroup: it.comp.os.linux.sys
Titolo: problema core dump TAR

Ciao a tutti,
mi scuso subito per la lunghezza...
ho un file server sul quale ho trasferito tutta la cartella di file 
condivisi di una piccola azienda. Sono circa 1.5G di file vari, da word 
a mp3 a immagini di CD.
Ogni notte eseguo (via cron) il backup con tar salvando l'archivio su 
un'altra partizione che poi va in rsync su un altro PC remoto.
Il processo di TAR non ce la fa. Va in core dump sia che comprima con 
gzip che con bzip2. Inoltre va in coredump anche rsync e un altro 
processo di cron che non conosco... (credo l'aggiornamento dei pacchetti 
installati)
Il problema di TAR non è in se un grave problema, salvo che non sto 
facendo i backup. Il guaio è che si porta indietro l'intero sistema, 
senza però bloccarlo del tutto. I server vanno tutti (samba, imap, sshd, 
apache+php) ma nel caso per esempio di sshd se mi connetto mi chiede 
utente e password e poi si blocca. Imapd va senza problemi ma fetchmail 
non va in esecuzione e quindi non ho posta nuova.
Il server in questione ha avuto un uptime di due mesi senza alcun 
problema. Il caos è avvenuto da quando ho trasferito questi file.
Idee? Suggerimenti?
OS: Linux Trustix (RH based) con kernel 2.4.30
Grazie!
Alex

 installati)
Ciao,
 che errore ti danno? Hai idea del motivo per cui falliscono?
 Ciao
 Federico

  che errore ti danno? Hai idea del motivo per cui falliscono?
Segmentation fault, forse peggio della BSOD...
Ieri ho fatto solo "tar cf" con compressione gzip successiva sul file 
creato e non ha dato problemi.
Non posso però fare troppi test poiché il server in questione è "di 
produzione" e non ce l'ho sottomano. Vorrei arrivare dal cliente 
preparato e non buttar via un pomeriggio a fare prove per poi ritrovarmi 
il mattino successivo con il server inchiodato.
Questo è quello che mi ha inviato fcron:
==========
/bin/tar: Removing leading `/' from member names
/etc/cron.daily/backup.cron: line 55:   865 Segmentation fault      $TAR 
$NEWER -cjf $BACKUPDIR/$COMPUTER-$DOW.tar.bz2 $DIRECTORIES
/etc/cron.daily/rsync: line 3:   970 Segmentation fault      rsync -az 
--exclude "MasterMp3/" --exclude "mirror-*/" -e "ssh -p222" --stats -v 
/backups/* XXUTE...@XXSERVERXX.dyndns.org:backup 
 >>/var/log/rsync-backup 2>>/var/log/rsync-backup
/usr/bin/updatedb: line 31:   976 Segmentation fault      slocate $FROM 
$VERBOSE -l $SECURITY -d $DATABASE -f "$FSEXCLUDE" -e "$EXCLUDE"
==========
Grazie
Alex.

 $NEWER -cjf $BACKUPDIR/$COMPUTER-$DOW.tar.bz2 $DIRECTORIES
c'è poco da fare , o l' hw è bacato o hai un tar con un bug , prova a fare:
strace <comando tar completo> 2> /<dovetipare>/segfault.log 
e poi vedere di preciso dove schianta.
ps: hai visto se ci sono aggiornamenti ?
-- 
"In Brasile ci sono solo puttane e calciatori".
"Ti ricordo che mia moglie e' brasiliana!".
"Aahh...  e in che squadra gioca?".
                -- Da it.hobby.umorismo

 compressione, che tu abbia le zlib bacate?
Era anche il mio sospetto, motivo per cui ho provato sia l'opzione z 
(gzip) che j (bzip2), sia anche il giro lungo di creare il tar non 
compresso e di comprimerlo in un secondo momento con gzip.
Ho provato a lanciare durante la pausa pranzo il comando completo (tar 
cjv) ed č andato a buon fine. Boh... Forse un problema hw? Ne sarei 
molto sorpreso visto che quel "server" era prima un PC di uso quotidiano 
a cui č stato "donato" un nuovo disco.
Grazie
Alex.

 ps: hai visto se ci sono aggiornamenti ?
tar 1.14, risulta essere la versione più recente offerta da questa distro.
Grazie!
Alex.

 non uso piů distro rpm-based da tempo ma sono sicuro che c'č !)
sarei anche io per quello che avete gia' detto in molti se non per il fatto
che i programmi di (de)compressione usano in maniera piuttosto intensiva la
memoria di sistema. Mi chiedo quindi se non sarebbe il caso di testare a
fondo la ram. Magari non se n'era accorto prima perche' non aveva mai
provato a comprimere file piuttosto grandi.
-- 
Pandozy vede tutto
    _     _
  o' |,=./ `o
     (o o)    
 ooO--(_)--Ooo-

 
Volevo provarla per scrupolo la prossima volta che sarei stato nelle 
"vicinanze" anche se però quel computer è stato usato come PC da un paio 
d'anni usando applicazioni come OpenOffice (su Win2k PRO), che di RAM è 
abbastanza golosa.
Giustificherebbe anche la casualità dell'errore.
Al momento ho un processo TAR e uno BZIP2 che si sono bloccati e non ne 
vogliono sapere di morire: kill -9 1629 non sortisce alcun effetto.
Intanto grazie a tutti per l'interessamento!
Alex.

 Alex.
faccesape'
ciao


 faccesape'
Oggi ho sostituito il chip di RAM con uno verificato funzionate.
Ho avviato il processo di TAR (+BZIP2) che però si è interrotto di 
nuovo. In /var/log/messages ho trovato i messaggi del kernel che allego 
in calce.
Spero la formattazione non lo renda illeggibile.
Vedendo menzione di problemi legati al filesystem ho eseguito un 
approfondito fsck, compreso anche un test usando smartctl. Tutto bene, 
nessun errore. Altri suggerimenti?
Grazie a tutti per l'interessamento fin'ora!
Alex.
=======================================================
invalid operand: 0000
CPU:    0
EIP:    0010:[rmqueue+365/704]    Not tainted
EFLAGS: 00010006
eax: 0000fff0   ebx: 00000002   ecx: 00005128   edx: c02c7858
esi: c02c789c   edi: 00000001   ebp: c10f37a0   esp: cad97e74
ds: 0018   es: 0018   ss: 0018
Process tar (pid: 890, stackpage=cad97000)
Stack: 00001000 00001000 00004128 00004128
        00000296 00000000 c02c7858 c02c7858
        c02c7a2c 00000001 00000000 c0133719
        c10f3800 c0131ce8 c10f3800 c5f076d4
        c02c7858 c02c7a28 000001d2 c016287f
        c5f076d4 0000000c 00007fde cff64ea8
Call Trace:    [__alloc_pages+121/624] [lru_cache_add+88/112]
                [ext3_readpage+15/32] [page_cache_read+103/176]
                [generic_file_readahead+206/400]
                [do_generic_file_read+406/1088] [file_read_actor+0/240] 
                [generic_file_read+149/400] [file_read_actor+0/240]
                [pipe_write+330/672] [sys_read+99/176]
                [system_call+51/64]
Code: 31 c0 8a 45 1b 3b 14 85 70 51 33 c0 74 0d 90 8d 74 26 00 0f
=======================================================