"Nicolas Sahlqvist" <nicco77@xxxxxxxxx> wrote:
First you have to figure out if the problem occurs in tar or gzip, do you
get the problem if you tar and then gzip or is it combined (make a none
compressed tar archive), in case no is the pipe somehow the problem, same
crash with tar -z option rather then piping to gzip? Finally you need to get
a stack trace why you need to set the core size limit above the default 0
size with "ulimit -c unlimited" before running the command. You can now use
gdb to make a stack trace "gdb <path to exec file> <path to core file>" and
type where and type "where" in order to get a stack trace that you can
publish in a relevant forum for further examination by developers.
- Nicolas
and John Hinton <webmaster@xxxxxxxx> wrote
Sounds like your tmp directory isn't big enough to handle the creation
of the tar file. I'm pretty sure it's stored there until it's created
and zipped. Then once done is moved to the destination. If you do a df
from the command line several times while running the script, you can
see if an area is filling up before completion.
John Hinton
When I checked the server this morning it had a kernel panic (in
sendbackup) . I got it cleaned up and back running and tried again to
recreate the problem. This time my tar command worked just fine
(Nicholas, I'm using tar piped to gzip to mimic what amanda does). I
tried it again and got a seg fault from a file that had just been tarred
and gzipped with no problem. I fired it off again and got the seg fault
from a different file.
At this point I'm thinking I have an intermittent hardware problem. It
just happened to seg fault twice on the same file when I tried it
yesterday. After several runs, there appear to be certain files that I
preferentially get the seg fault on if I rerun the backup several
times. Sometimes it works; sometimes it seg faults. When it seg faults
it's frequently on certain specific files. Kind of weird.
Hopefully, it's nothing worse than the CPU fan has ingested too much cat
hair (http://davenjudy.org/interests/pets/img011.jpeg.medium.jpeg) so
the CPU is running hot. Thanks for the help.
Cheers,
Dave
--
Politics, n. Strife of interests masquerading as a contest of principles.
-- Ambrose Bierce
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
