If I manually run the following gtar command I get a segmentation fault
/usr/sfw/bin/gtar --create
> --file /dev/null --numeric-owner --directory
> /zvol/backup/gauss/.zfs/snapshot/BKUPTODAY/export/jumpstart --one-file-
> system --listed-incremental /var/amanda/gnutar-
> lists/hertz_export_jumpstart_0.new --sparse --ignore-failed-read --
> totals .
If I run the command with /zvol/backup/gauss/export/jumpstart then it works as
advertised.
When I ran truss on the first gtar with the .zfs in the path I get
chdir("/zvol/backup/gauss/.zfs/snapshot/BKUPTODAY/export/jumpstart") = 0
fstat64(4, 0x080478F0) = 0
brk(0x080B5F00) = 0
brk(0x080C5F00) = 0
fstat64(4, 0x08047830) = 0
ioctl(4, TCGETA, 0x080478C4) Err#25 ENOTTY
read(4, " G N U t a r - 1 . 2 3".., 69632) = 69159
brk(0x080C5F00) = 0
brk(0x080C7F00) = 0
lstat64(".", 0x08047780) = 0
lstat64("/", 0x08047780) = 0
openat64(-3041965, "..", O_RDONLY) = 6
fstat64(6, 0x08047780) = 0
fcntl(6, F_SETFD, 0x00000001) = 0
fstat64(6, 0x080476D0) = 0
getdents64(6, 0xFEED4000, 8192) = 192
fstatat64(6, "jumpstart", 0x08047780, 0x00001000) = 0
openat64(6, "..", O_RDONLY) = 7
fstat64(7, 0x08047780) = 0
close(6) = 0
fcntl(7, F_SETFD, 0x00000001) = 0
fstat64(7, 0x080476D0) = 0
getdents64(7, 0xFEED4000, 8192) = 136
fstatat64(7, "export", 0x08047780, 0x00001000) = 0
openat64(7, "..", O_RDONLY) = 6
fstat64(6, 0x08047780) = 0
close(7) = 0
fcntl(6, F_SETFD, 0x00000001) = 0
fstat64(6, 0x080476D0) = 0
getdents64(6, 0xFEED4000, 8192) = 720
fstatat64(6, "DAILY-201005020315", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004280315", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004211815", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004300315", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004290315", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004270315", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201005030315", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004201815", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004181815", 0x08047780, 0x00001000) = 0
fstatat64(6, "DAILY-201004251830", 0x08047780, 0x00001000) = 0
fstatat64(6, "BKUPTODAY", 0x08047780, 0x00001000) = 0
openat64(6, "..", O_RDONLY) = 7
fstat64(7, 0x08047780) = 0
close(6) = 0
fcntl(7, F_SETFD, 0x00000001) = 0
fstat64(7, 0x080476D0) = 0
getdents64(7, 0xFEED4000, 8192) = 80
fstatat64(7, "snapshot", 0x08047780, 0x00001000) = 0
openat64(7, "..", O_RDONLY) = 6
fstat64(6, 0x08047780) = 0
close(7) = 0
***where is .zfs*** ?
fcntl(6, F_SETFD, 0x00000001) = 0
fstat64(6, 0x080476D0) = 0
getdents64(6, 0xFEED4000, 8192) = 136
getdents64(6, 0xFEED4000, 8192) = 0
llseek(6, 0, SEEK_CUR) = 0x1A0F2126
llseek(6, 0, SEEK_SET) = 0
getdents64(6, 0xFEED4000, 8192) = 136
fstatat64(6, "rpoolbackup", 0x08047780, 0x00001000) = 0
fstatat64(6, "root", 0x08047780, 0x00001000) = 0
fstatat64(6, "export", 0x08047780, 0x00001000) = 0
getdents64(6, 0xFEED4000, 8192) = 0
close(6) = 0
Incurred fault #6, FLTBOUNDS %pc = 0x0807DDA5
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
Received signal #11, SIGSEGV [default]
siginfo: SIGSEGV SEGV_MAPERR addr=0x00000000
> -----Original Message-----
> From: [email protected] [mailto:[email protected]] On Behalf Of
> Dustin J. Mitchell
> Sent: Monday, May 03, 2010 5:18 PM
> To: McGraw, Robert P
> Cc: [email protected]
> Subject: Re: runtar error that I do not understand
>
>
> On Mon, May 3, 2010 at 2:01 PM, McGraw, Robert P <[email protected]>
> wrote:
> > hertz /export/jumpstart lev 0 FAILED "[/local/amanda/amanda-
> 2.6.1p2/libexec/amanda/runtar terminated with signal 11: see
> /tmp/amanda/client/archive/sendsize.20100503144020.debug]"
>
> signal 11 is a segfault. The last line of the 'runtar' logfile shows
> that it invokes dbclose, and the very next statement is an execve,
> which is failing. I'm not sure exactly why this would be happening,
> unless GNUTAR is undefined in your build?
>
> Anyway, the segfault is either coming from the execve, or from the
> debugging code that follows it. However, I just forced an error from
> execve, and the debugging code worked fine. And I don't immediately
> see anything wrong with it.
>
> Try invoking runtar the same way that you see in the sendbackup
> logfile (with suitable redirection of stdout), and see if it does the
> same thing. If so, try running it under 'truss' to see what is wrong
> with the execve call.
>
> Dustin
>
> --
> Open Source Storage Engineer
> http://www.zmanda.com
