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: djmit...@gmail.com [mailto:djmit...@gmail.com] On Behalf Of > Dustin J. Mitchell > Sent: Monday, May 03, 2010 5:18 PM > To: McGraw, Robert P > Cc: amanda-users@amanda.org > Subject: Re: runtar error that I do not understand > > > On Mon, May 3, 2010 at 2:01 PM, McGraw, Robert P <rmcg...@purdue.edu> > 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