RE: runtar error that I do not understand
FYI: This is the information that Chapman Flack has submitted to bug-tar. J Chapman Flack wrote: I've submitted a report that's awaiting moderator approval. I can send you the link to it on bug-tar as soon as it goes through. http://lists.gnu.org/archive/html/bug-tar/2010-06/msg0.html There was a similar report (different circumstances, but very likely the same bug) reported last week: http://lists.gnu.org/archive/html/bug-tar/2010-05/msg00026.html -Chap -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda- us...@amanda.org] On Behalf Of McGraw, Robert P Sent: Wednesday, June 02, 2010 11:23 AM To: 'Nathan Stratton Treadway'; 'amanda-users@amanda.org' Cc: 'jfl...@math.purdue.edu' Subject: RE: runtar error that I do not understand I am not sure if this got sent to the group so I an fordwarding. This explains what is going on in the gtar code to cause gtar to seg fault. All the accolades should go to my SA partner Chapman Flack. He is in the process of sending this to bug-tar as suggested. Robert Apparently under only some circumstances, gtar tries to use the old algorithm for finding the cwd. That fails beneath .zfs which is a sort of magical name that isn't there unless you're looking for it exactly. But it must just be a special combination of options that makes gtar try to do that, because in simple invocations it doesn't: hertz /homes % ls .z*# nobody here but us chickens... ls: No match. hertz /homes % cd .zfs # oh, you mean ME? hertz .zfs % cd snapshot/TODAY/jflack % gtar --create --file /dev/null bar # works fine Aha, it's the --listed-incremental option. This makes gtar want to create the snar file with names and metadata of files it sees: % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar Segmentation fault The funny thing is, if I cd to ~ where it works... % cd ~ % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar % ...and then look in /tmp/snar, it only contains relative paths... ...so it STILL doesn't explain why gtar even wants to get the cwd in that case, but it's clear from the truss that's what it's doing. One workaround might be to do a loopback mount of the desired snapshot onto some other path that's not beneath .zfs, and do the backup from there. -Chap -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda- us...@amanda.org] On Behalf Of Nathan Stratton Treadway Sent: Tuesday, May 04, 2010 2:45 PM To: amanda-users@amanda.org Subject: Re: runtar error that I do not understand On Tue, May 04, 2010 at 13:03:09 -0500, Dustin J. Mitchell wrote: On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I setup a lookback for the snapshot and now gtar seem to be working. It sounds like you have a fairly good understanding of this problem now. Could you write up either a troubleshooting or How-To article on the wiki? Also, you might want to send a bug report about this to the bug-...@gnu.org list -- even if the underlying problem is that .zfs doesn't behave normally, I suspect they'd be interested in knowing about the issue so that they can at least avoid having an abort-with- segfault in that situation... http://www.gnu.org/software/tar/#maillists Nathan - -- - Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: runtar error that I do not understand
I am not sure if this got sent to the group so I an fordwarding. This explains what is going on in the gtar code to cause gtar to seg fault. All the accolades should go to my SA partner Chapman Flack. He is in the process of sending this to bug-tar as suggested. Robert Apparently under only some circumstances, gtar tries to use the old algorithm for finding the cwd. That fails beneath .zfs which is a sort of magical name that isn't there unless you're looking for it exactly. But it must just be a special combination of options that makes gtar try to do that, because in simple invocations it doesn't: hertz /homes % ls .z*# nobody here but us chickens... ls: No match. hertz /homes % cd .zfs # oh, you mean ME? hertz .zfs % cd snapshot/TODAY/jflack % gtar --create --file /dev/null bar # works fine Aha, it's the --listed-incremental option. This makes gtar want to create the snar file with names and metadata of files it sees: % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar Segmentation fault The funny thing is, if I cd to ~ where it works... % cd ~ % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar % ...and then look in /tmp/snar, it only contains relative paths... ...so it STILL doesn't explain why gtar even wants to get the cwd in that case, but it's clear from the truss that's what it's doing. One workaround might be to do a loopback mount of the desired snapshot onto some other path that's not beneath .zfs, and do the backup from there. -Chap -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda- us...@amanda.org] On Behalf Of Nathan Stratton Treadway Sent: Tuesday, May 04, 2010 2:45 PM To: amanda-users@amanda.org Subject: Re: runtar error that I do not understand On Tue, May 04, 2010 at 13:03:09 -0500, Dustin J. Mitchell wrote: On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I setup a lookback for the snapshot and now gtar seem to be working. It sounds like you have a fairly good understanding of this problem now. Could you write up either a troubleshooting or How-To article on the wiki? Also, you might want to send a bug report about this to the bug-...@gnu.org list -- even if the underlying problem is that .zfs doesn't behave normally, I suspect they'd be interested in knowing about the issue so that they can at least avoid having an abort-with-segfault in that situation... http://www.gnu.org/software/tar/#maillists Nathan --- - Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: runtar error that I do not understand
As a workaround, perhaps you could unhide the snapshot directory. man zfs. McGraw, Robert P wrote at 11:23 -0400 on Jun 2, 2010: I am not sure if this got sent to the group so I an fordwarding. This explains what is going on in the gtar code to cause gtar to seg fault. All the accolades should go to my SA partner Chapman Flack. He is in the process of sending this to bug-tar as suggested. Robert Apparently under only some circumstances, gtar tries to use the old algorithm for finding the cwd. That fails beneath .zfs which is a sort of magical name that isn't there unless you're looking for it exactly. But it must just be a special combination of options that makes gtar try to do that, because in simple invocations it doesn't: hertz /homes % ls .z*# nobody here but us chickens... ls: No match. hertz /homes % cd .zfs # oh, you mean ME? hertz .zfs % cd snapshot/TODAY/jflack % gtar --create --file /dev/null bar # works fine Aha, it's the --listed-incremental option. This makes gtar want to create the snar file with names and metadata of files it sees: % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar Segmentation fault The funny thing is, if I cd to ~ where it works... % cd ~ % gtar --create --file /dev/null --listed-incremental=/tmp/snar bar % ...and then look in /tmp/snar, it only contains relative paths... ...so it STILL doesn't explain why gtar even wants to get the cwd in that case, but it's clear from the truss that's what it's doing. One workaround might be to do a loopback mount of the desired snapshot onto some other path that's not beneath .zfs, and do the backup from there. -Chap -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda- us...@amanda.org] On Behalf Of Nathan Stratton Treadway Sent: Tuesday, May 04, 2010 2:45 PM To: amanda-users@amanda.org Subject: Re: runtar error that I do not understand On Tue, May 04, 2010 at 13:03:09 -0500, Dustin J. Mitchell wrote: On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I setup a lookback for the snapshot and now gtar seem to be working. It sounds like you have a fairly good understanding of this problem now. Could you write up either a troubleshooting or How-To article on the wiki? Also, you might want to send a bug report about this to the bug-...@gnu.org list -- even if the underlying problem is that .zfs doesn't behave normally, I suspect they'd be interested in knowing about the issue so that they can at least avoid having an abort-with-segfault in that situation... http://www.gnu.org/software/tar/#maillists Nathan --- - Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: runtar error that I do not understand
-Original Message- From: djmit...@gmail.com [mailto:djmit...@gmail.com] On Behalf Of Dustin J. Mitchell Sent: Monday, May 03, 2010 5:42 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 4:31 PM, McGraw, Robert P rmcg...@purdue.edu wrote: If I manually run the following gtar command I get a segmentation fault /usr/sfw/bin/gtar --create Uh-oh .. time to open a Sun^WOracle support case? It looks like a bug either in ZFS or GNU Tar.. Dustin -- Open Source Storage Engineer http://www.zmanda.com [McGraw, Robert P] Have you every tried star. I though I would give it a shot and see if it work ok at least until I can get the GNU tar working. Thanks Robert
RE: runtar error that I do not understand
, 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. You need version with --no-check-device in order to backup snapshot in zfs. So get the latest version of SMCtar and it should work fine. bash-3.00$ /usr/local/bin/tar --version tar (GNU tar) 1.20 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Best regards GG Dustin J. Mitchell Sent: Monday, May 03, 2010 5:42 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 4:31 PM, McGraw, Robert P rmcg...@purdue.edu wrote: If I manually run the following gtar command I get a segmentation fault /usr/sfw/bin/gtar --create Uh-oh .. time to open a Sun^WOracle support case? It looks like a bug either in ZFS or GNU Tar.. Dustin -- Open Source Storage Engineer http://www.zmanda.com [McGraw, Robert P] Have you every tried star. I though I would give it a shot and see if it work ok at least until I can get the GNU tar working. Thanks Robert
Re: runtar error that I do not understand
-Original Message- From: Gunnarsson, Gunnar [mailto:gunnar.gunnars...@svk.se] Sent: Tuesday, May 04, 2010 9:09 AM To: McGraw, Robert P; 'Dustin J. Mitchell' Cc: 'amanda-users@amanda.org' Subject: SV: runtar error that I do not understand Sun is delivering old versions of GNU tar: Written by John Gilmore and Jay Fenlason. bash-3.00$ /usr/sfw/bin/gtar --version tar (GNU tar) 1.14 Copyright (C) 2004 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. You need version with --no-check-device in order to backup snapshot in zfs. So get the latest version of SMCtar and it should work fine. bash-3.00$ /usr/local/bin/tar --version tar (GNU tar) 1.20 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Best regards GG Dustin J. Mitchell Sent: Monday, May 03, 2010 5:42 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 4:31 PM, McGraw, Robert P rmcg...@purdue.edu wrote: If I manually run the following gtar command I get a segmentation fault /usr/sfw/bin/gtar --create Uh-oh .. time to open a Sun^WOracle support case? It looks like a bug either in ZFS or GNU Tar.. Dustin -- Open Source Storage Engineer http://www.zmanda.com [McGraw, Robert P] Have you every tried star. I though I would give it a shot and see if it work ok at least until I can get the GNU tar working. Thanks Robert --- Brian R Cuttler brian.cutt...@wadsworth.org Computer Systems Support(v) 518 486-1697 Wadsworth Center(f) 518 473-6384 NYS Department of HealthHelp Desk 518 473-0773 IMPORTANT NOTICE: This e-mail and any attachments may contain confidential or sensitive information which is, or may be, legally privileged or otherwise protected by law from further disclosure. It is intended only for the addressee. If you received this in error or from someone who was not authorized to send it to you, please do not distribute, copy or use it or any attachments. Please notify the sender immediately by reply e-mail and delete this from your system. Thank you for your cooperation.
Re: runtar error that I do not understand
On Tue, May 4, 2010 at 9:33 AM, McGraw, Robert P rmcg...@purdue.edu wrote: Is there someone in the zmanda world that has the following amanda setup. 1) Solaris x86 Solaris 10 2) /usr/sfw/bin/gtar (v1.23) 3) amanda 2.6.1p2 4) amanda backup of a zfs snapshot like /path/.zfs/snapshot/path/to/dir I am getting a seg fault when gtar tries to get the size of the zfs snapshot directory. I believe it has to do with .zfs as a hidden directory and I am not sure how to get around this. (since you mentioned Zmanda specifically..) We don't have a ZFS setup at the moment, and in fact our Sparc systems are fairly limited since they can't be fully virtualized. I'm borrowing time on some Solaris systems from a friend today, so if I get a chance and can set up ZFS, I'll give it a whirl. That said, I suspect that if the bug were as large as gtar on a ZFS snapshot segfaults, it would be fixed already, so the circumstances are likely more narrow. Have you checked the Solaris bug tracker? Do your system logs give any indication of what's going on? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: runtar error that I do not understand
(C) 2009 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by John Gilmore and Jay Fenlason. That is the gnutar release from 3/09, and the only newer one is 1.23 from 3/10. But, I had done an upgrade late last year (using liveupdate and the 5/09 release), and have also applied the latest recommended and security patch bundles within the last few months. So, I have # more /etc/release Solaris 10 5/09 s10s_u7wos_08 SPARC Copyright 2009 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 30 March 2009 All of which means, check what your system actually has (and keep it up to date). --- Chris Hoogendyk - O__ Systems Administrator c/ /'_ --- Biology Geology Departments (*) \(*) -- 140 Morrill Science Center ~~ - University of Massachusetts, Amherst hoogen...@bio.umass.edu --- Erdös 4 Gunnarsson, Gunnar wrote: Sun is delivering old versions of GNU tar: Written by John Gilmore and Jay Fenlason. bash-3.00$ /usr/sfw/bin/gtar --version tar (GNU tar) 1.14 Copyright (C) 2004 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. You need version with --no-check-device in order to backup snapshot in zfs. So get the latest version of SMCtar and it should work fine. bash-3.00$ /usr/local/bin/tar --version tar (GNU tar) 1.20 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Best regards GG Dustin J. Mitchell Sent: Monday, May 03, 2010 5:42 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 4:31 PM, McGraw, Robert P rmcg...@purdue.edu wrote: If I manually run the following gtar command I get a segmentation fault /usr/sfw/bin/gtar --create Uh-oh .. time to open a Sun^WOracle support case? It looks like a bug either in ZFS or GNU Tar.. Dustin -- Open Source Storage Engineer http://www.zmanda.com [McGraw, Robert P] Have you every tried star. I though I would give it a shot and see if it work ok at least until I can get the GNU tar working. Thanks Robert --
Re: runtar error that I do not understand
On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I setup a lookback for the snapshot and now gtar seem to be working. It sounds like you have a fairly good understanding of this problem now. Could you write up either a troubleshooting or How-To article on the wiki? Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: runtar error that I do not understand
On Tue, May 04, 2010 at 13:03:09 -0500, Dustin J. Mitchell wrote: On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I setup a lookback for the snapshot and now gtar seem to be working. It sounds like you have a fairly good understanding of this problem now. Could you write up either a troubleshooting or How-To article on the wiki? Also, you might want to send a bug report about this to the bug-...@gnu.org list -- even if the underlying problem is that .zfs doesn't behave normally, I suspect they'd be interested in knowing about the issue so that they can at least avoid having an abort-with-segfault in that situation... http://www.gnu.org/software/tar/#maillists Nathan Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
RE: runtar error that I do not understand
I will do both suggestions. I leave for vacation tomorrow so it might be next week before I can get to it. Robert -Original Message- From: owner-amanda-us...@amanda.org [mailto:owner-amanda- us...@amanda.org] On Behalf Of Nathan Stratton Treadway Sent: Tuesday, May 04, 2010 2:45 PM To: amanda-users@amanda.org Subject: Re: runtar error that I do not understand On Tue, May 04, 2010 at 13:03:09 -0500, Dustin J. Mitchell wrote: On Tue, May 4, 2010 at 12:27 PM, McGraw, Robert P rmcg...@purdue.edu wrote: I setup a lookback for the snapshot and now gtar seem to be working. It sounds like you have a fairly good understanding of this problem now. Could you write up either a troubleshooting or How-To article on the wiki? Also, you might want to send a bug report about this to the bug-...@gnu.org list -- even if the underlying problem is that .zfs doesn't behave normally, I suspect they'd be interested in knowing about the issue so that they can at least avoid having an abort-with-segfault in that situation... http://www.gnu.org/software/tar/#maillists Nathan --- - Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region Ray Ontko Co. - Software consulting services - http://www.ontko.com/ GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239 Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
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
Re: runtar error that I do not understand
On Mon, May 3, 2010 at 4:31 PM, McGraw, Robert P rmcg...@purdue.edu wrote: If I manually run the following gtar command I get a segmentation fault /usr/sfw/bin/gtar --create Uh-oh .. time to open a Sun^WOracle support case? It looks like a bug either in ZFS or GNU Tar.. Dustin -- Open Source Storage Engineer http://www.zmanda.com
RE: runtar error that I do not understand
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, 0x0001) = 0 fstat64(6, 0x080476D0) = 0 getdents64(6, 0xFEED4000, 8192) = 192 fstatat64(6, jumpstart, 0x08047780, 0x1000) = 0 openat64(6, .., O_RDONLY) = 7 fstat64(7, 0x08047780) = 0 close(6)= 0 fcntl(7, F_SETFD, 0x0001) = 0 fstat64(7, 0x080476D0) = 0 getdents64(7, 0xFEED4000, 8192) = 136 fstatat64(7, export, 0x08047780, 0x1000) = 0 openat64(7, .., O_RDONLY) = 6 fstat64(6, 0x08047780) = 0 close(7)= 0 fcntl(6, F_SETFD, 0x0001) = 0 fstat64(6, 0x080476D0) = 0 getdents64(6, 0xFEED4000, 8192) = 720 fstatat64(6, DAILY-201005020315, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004280315, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004211815, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004300315, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004290315, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004270315, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201005030315, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004201815, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004181815, 0x08047780, 0x1000) = 0 fstatat64(6, DAILY-201004251830, 0x08047780, 0x1000) = 0 fstatat64(6, BKUPTODAY, 0x08047780, 0x1000) = 0 openat64(6, .., O_RDONLY) = 7 fstat64(7, 0x08047780) = 0 close(6)= 0 fcntl(7, F_SETFD, 0x0001) = 0 fstat64(7, 0x080476D0) = 0 getdents64(7, 0xFEED4000, 8192) = 80 fstatat64(7, snapshot, 0x08047780, 0x1000) = 0 openat64(7, .., O_RDONLY) = 6 fstat64(6, 0x08047780) = 0 close(7)= 0 ***where is .zfs*** ? fcntl(6, F_SETFD, 0x0001) = 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, 0x1000) = 0 fstatat64(6, root, 0x08047780, 0x1000)= 0 fstatat64(6, export, 0x08047780, 0x1000) = 0 getdents64(6, 0xFEED4000, 8192) = 0 close(6)= 0 Incurred fault #6, FLTBOUNDS %pc = 0x0807DDA5 siginfo: SIGSEGV SEGV_MAPERR addr=0x Received signal #11, SIGSEGV [default] siginfo: SIGSEGV SEGV_MAPERR addr=0x -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
