hi...
I had a look at into the '/tmp/amanda/client/weekly/sendbackup*' files,
and they all show the same failure:
sendbackup: time 89.994: index tee cannot write [Broken pipe]
Also this failure occurs constantly around second 89 to 90.
A complete sendbackup logfile looks like this:
================================================
sendbackup: debug 1 pid 21923 ruid 501 euid 501: start at Thu Mar 27
08:50:07 2008
sendbackup: version 2.5.2p1
Could not open conf file "/usr/local/etc/amanda/amanda-client.conf": No
such file or directory
Could not open conf file
"/usr/local/etc/amanda/weekly/amanda-client.conf": No such file or
directory
sendbackup: debug 1 pid 21923 ruid 501 euid 501: rename at Thu Mar 27
08:50:07 2008
sendbackup req: <GNUTAR / 0 1970:1:1:0:0:0 OPTIONS
|;auth=bsd;index;exclude-list=/etc/amanda/weekly-exclude;>
parsed request as: program `GNUTAR'
disk `/'
device `/'
level 0
since 1970:1:1:0:0:0
options
`|;auth=bsd;index;exclude-list=/etc/amanda/weekly-exclude;'
sendbackup: start: 172.31.3.9:/ lev 0
sendbackup-gnutar: time 0.001: doing level 0 dump as listed-incremental
to '/var/amanda/gnutar-lists/172.31.3.9__0.new'
sendbackup-gnutar: time 0.001: doing level 0 dump from date: 1970-01-01
0:00:00 GMT
sendbackup: time 0.002: spawning /usr/local/libexec/runtar in pipeline
sendbackup: time 0.002: argument list: runtar weekly gtar --create
--file - --directory / --one-file-system --listed-incremental /var/ama
nda/gnutar-lists/172.31.3.9__0.new --sparse --ignore-failed-read
--totals --exclude-from /tmp/amanda/sendbackup._.20080327085007.exclude
.
sendbackup-gnutar: time 0.217: /usr/local/libexec/runtar: pid 21927
sendbackup: time 0.217: started backup
sendbackup: time 0.218: started index creator: "/bin/gtar -tf -
2>/dev/null | sed -e 's/^\.//'"
The tar version is:
====================
tar (GNU tar) 1.13.25
Copyright © 2001 Free Software Foundation, Inc.
This program comes with NO WARRANTY, to the extent permitted by law.
You may redistribute it under the terms of the GNU General Public
License;
see the file named COPYING for details.
Written by John Gilmore and Jay Fenlason.
>>From what the VMvware support told me the ESX system is based on RedHat
3 Update 6. Is it possible/ likely that they applied some (custom)
patches to gtar?
Regards,
Olli
Am Sonntag, den 30.03.2008, 16:14 -0400 schrieb Dustin J. Mitchell:
> OK, here's what I see in the 'strace' output, repeated 15
> thousand-some-odd times:
>
> write(1, "nfo\nc0121610 t __constant_c_and_"..., 10240) = -1 EPIPE (Broken
> pipe)
> --- SIGPIPE (Broken pipe) @ 0 (0) ---
>
> So for some reason gtar is ignoring the SIGPIPE signal. There's
> probably something else going wrong in Amanda, which is causing it to
> close the pipe into which tar is writing. You can probably find out
> whats going on by looking at the 'sendbackup' debug logs on the
> client, and I expect that if you fix the Amanda-side problem, you
> won't see any more trouble from GNU tar.
>
> The question is, why isn't tar doing the right thing when this happens?
>
> I tested my local copy of tar like this:
> $ strace -f tar -cf - . 2>/tmp/trace | true; tail /tmp/trace
> mmap(NULL, 821, PROT_READ, MAP_SHARED, 3, 0) = 0x2af4a8ffb000
> lseek(3, 821, SEEK_SET) = 821
> munmap(0x2af4a8ffb000, 821) = 0
> close(3) = 0
> lstat("./ABOUT-NLS", {st_mode=S_IFREG|0644, st_size=38475, ...}) = 0
> open("./ABOUT-NLS", O_RDONLY) = 3
> read(3, "Notes on the Free Translation Pr"..., 9216) = 9216
> write(1, "./\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"...,
> 10240) = -1 EPIPE (Broken pipe)
> --- SIGPIPE (Broken pipe) @ 0 (0) ---
> +++ killed by SIGPIPE +++
>
> I'm running tar 1.19, and also tested this against 1.15 and 1.13.25,
> and saw similar (that is, correct) behavior everywhere. What version
> of tar are you running?
>
> Dustin
|
