Re: SV: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
Hi, just wanted to send you an update on this issue. Switching to auth=bsdtcp completely solved my problem. The working line from /etc/inetd.conf (for openbsd-inetd, and the amanda-user being backup) is: amanda stream tcp nowait backup /usr/lib/amanda/amandad amandad -auth=bsdtcp amdump amindexd amidxtaped During the last 7 days there hasn't been a single failed backup on any of my previously affected systems. Thank you for your support! Volker
Re: SV: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
Hello again, unfortunately my dup2-problems reappeared after that one night when it was working, I still have the same error on my machines. so far I have only changed the entry in /etc/inetd.conf (I'm using openbsd-inetd) from: amanda dgram udp wait backup /usr/lib/amanda/amandad amandad -auth=bsd amdump amindexd amidxtaped to: amanda dgram tcp wait backup /usr/lib/amanda/amandad amandad -auth=bsd amdump amindexd amidxtaped and of course restarted the inetd process. Are there any other places I need to adapt when completely switching amanda to tcp? Is auth=bsdtcp mandatory? Thanks you, Volker Volker Pallas wrote: Gunnarsson, Gunnar wrote: Switching to tcp instead of using udp cured those problems. Hi, I'm having a bit of a problem on *some* servers concerning failed backups with the error message: lev # FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] Gunnar had a similar problem - maybe his experience will help? http://www.mail-archive.com/amanda-users@amanda.org/msg42119.html Dustin
Re: SV: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
On Wed, Apr 21, 2010 at 11:04 AM, Volker Pallas ama...@sqmail.de wrote: Is auth=bsdtcp mandatory? If you want to switch to bsdtcp, then yes. You'll also need to change your (x)inetd configuration accordingly. The amanda-auth(7) manpage may be of use to you in figuring the whole thing out. DUstin -- Open Source Storage Engineer http://www.zmanda.com
Re: SV: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
Thank you Gunnar and Dustin! I switched to tcp on one host yesterday and it worked fine so far. I will observe this for the next couple of days and report back to you. Thank you again for your fast response, Volker Gunnarsson, Gunnar wrote: Switching to tcp instead of using udp cured those problems. Hi, I'm having a bit of a problem on *some* servers concerning failed backups with the error message: lev # FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] Gunnar had a similar problem - maybe his experience will help? http://www.mail-archive.com/amanda-users@amanda.org/msg42119.html Dustin
SV: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
Switching to tcp instead of using udp cured those problems. -- GG -Ursprungligt meddelande- Från: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] För Dustin J. Mitchell Skickat: den 13 april 2010 18:11 Till: Volker Pallas Kopia: amanda-users@amanda.org Ämne: Re: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2 On Mon, Apr 12, 2010 at 4:48 AM, Volker Pallas ama...@sqmail.de wrote: Hi, I'm having a bit of a problem on *some* servers concerning failed backups with the error message: lev # FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] Gunnar had a similar problem - maybe his experience will help? http://www.mail-archive.com/amanda-users@amanda.org/msg42119.html Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
On Mon, Apr 12, 2010 at 4:48 AM, Volker Pallas ama...@sqmail.de wrote: Hi, I'm having a bit of a problem on *some* servers concerning failed backups with the error message: lev # FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] Gunnar had a similar problem - maybe his experience will help? http://www.mail-archive.com/amanda-users@amanda.org/msg42119.html Dustin -- Open Source Storage Engineer http://www.zmanda.com
FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] on 2.6.1p2
Hi, I'm having a bit of a problem on *some* servers concerning failed backups with the error message: lev # FAILED [spawn /bin/gzip: dup2 out: Bad file descriptor] usually these failed backups are successfully retried, but sometimes I get the same error twice and the backup for the day fails completely. This only happens on servers backing up windows clients via smb-share/smbclient which are running amanda version 2.6.1p2. Servers with Linux clients are not affected and other versions of amanda backing up windows clients are also not affected. Additionally, as I said, this does not happen all the time and not always with the same clients. I verified amanda-user-access to /dev/null and I would rule out that the file systems are suddenly corrupt on all these different servers. I would like to know what this error message means and how to fix it or maybe you can point me in the right direction. If you need any more information, please tell me. Thank you in advance, Volker some detailed output from sendbackup.*.debug (this time failed and then retried successfully): 1270767389.972013: sendbackup: start: serverfqdn://ipaddr/backupshare$ lev 1 1270767389.972046: sendbackup: pipespawnv: stdoutfd is 50 1270767389.972078: sendbackup: Spawning /bin/gzip /bin/gzip --fast in pipeline 1270767389.972196: sendbackup: gnutar: pid 24511: /bin/gzip1270767389.972213: sendbackup: pid 24511: /bin/gzip --fast 1270767389.972347: sendbackup: critical (fatal): error [spawn /bin/gzip: dup2 out: Bad file descriptor] 1270767389.972928: sendbackup: gnutar: backup of \\ipaddr\backupshare$ 1270767389.973070: sendbackup: pipespawnv: stdoutfd is 6 1270767389.973188: sendbackup: Spawning /usr/bin/smbclient smbclient ipaddr\\backupshare$ -U username -E -d0 -Tqcg - in pipeline 1270767389.976787: sendbackup: Started index creator: /bin/tar -tf - 2/dev/null | sed -e 's/^\.//' 1270767389.979324: sendbackup: gnutar: /usr/bin/smbclient: pid 24513 1270767389.979343: sendbackup: Started backup software versions on affected servers: the OS is Debian Lenny amanda 2.6.1p2 gzip 1.3.12-6+lenny1 tar 1.20-1 smbclient 3.2.5-4lenny9
Amanda error: sendbackup: index tee cannot write [Bad file descriptor]
Hi! Amanda keeps having errors while its nightly run. not everytime, but most times: FAILED DUMP DETAILS: /-- adamantium /home/mol lev 1 FAILED [dump (17333) /bin/tar returned 2] sendbackup: start [adamantium:/home/mol level 1] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/tar -xpGf - ... sendbackup: info end ? sendbackup: index tee cannot write [Bad file descriptor] | Total bytes written: 71680 (70KiB, ?/s) ? /bin/tar: -: Wrote only 2048 of 10240 bytes ? /bin/tar: Error is not recoverable: exiting now ? index index returned 1 ? dump (17333) /bin/tar returned 2 sendbackup: error [dump (17333) /bin/tar returned 2] \ /-- adamantium /home/mol lev 1 FAILED [dump (17345) /bin/tar returned 2] sendbackup: start [adamantium:/home/mol level 1] sendbackup: info BACKUP=/bin/tar sendbackup: info RECOVER_CMD=/bin/tar -xpGf - ... sendbackup: info end ? sendbackup: index tee cannot write [Bad file descriptor] | Total bytes written: 10240 (10KiB, ?/s) ? /bin/tar: -: Cannot write: Broken pipe ? /bin/tar: Error is not recoverable: exiting now ? index index returned 1 ? dump (17345) /bin/tar returned 2 sendbackup: error [dump (17345) /bin/tar returned 2] \ What can we do, to fix this? kind regards, Alexander Schier
Cannot seek to 0: Bad file descriptor
Hello! I just upgraded to 2.5.0. Good job!! I am having some problems with my network machines (local machine is ok). This is an extract from my sendsize file: sendsize: debug 1 pid 18503 ruid 503 euid 503: start at Tue Apr 4 17:21:14 2006 sendsize: version 2.4.5 sendsize[18505]: time 0.006: calculating for amname '/usr/local/repo', dirname '/usr/local/repo', spindle -1 sendsize[18505]: time 0.006: getting size via gnutar for /usr/local/repo level 0 sendsize[18505]: time 0.007: spawning /usr/local/libexec/runtar in pipeline sendsize[18505]: argument list: /bin/gtar --create --file /dev/null --directory /usr/local/repo --one-file-system --list ed-incremental /usr/local/var/amanda/gnutar-lists/shinsaibashi_usr_local_repo_0.new --sparse --ignore-failed-read --tota ls . sendsize[18503]: time 0.008: waiting for any estimate child: 1 running sendsize[18505]: time 0.148: /bin/gtar: ./xxx/__db.003: Warning: Cannot seek to 0: Bad file descriptor sendsize[18505]: time 0.149: /bin/gtar: ./xxx/__db.004: Warning: Cannot seek to 0: Bad file descriptor sendsize[18505]: time 0.150: /bin/gtar: ./xxx/__db.001: Warning: Cannot seek to 0: Bad file descriptor sendsize[18505]: time 0.151: /bin/gtar: ./xxx/__db.003: Warning: Cannot seek to 0: Bad file descriptor And so on... Any ideas why this is so and what I should do about it? Thanks!!
Re: Cannot seek to 0: Bad file descriptor
On 2006-04-04 10:48, David Leangen wrote: Hello! I just upgraded to 2.5.0. Good job!! I am having some problems with my network machines (local machine is ok). This is an extract from my sendsize file: sendsize: debug 1 pid 18503 ruid 503 euid 503: start at Tue Apr 4 17:21:14 2006 sendsize: version 2.4.5 sendsize[18505]: time 0.006: calculating for amname '/usr/local/repo', dirname '/usr/local/repo', spindle -1 sendsize[18505]: time 0.006: getting size via gnutar for /usr/local/repo level 0 sendsize[18505]: time 0.007: spawning /usr/local/libexec/runtar in pipeline sendsize[18505]: argument list: /bin/gtar --create --file /dev/null --directory /usr/local/repo --one-file-system --list ed-incremental /usr/local/var/amanda/gnutar-lists/shinsaibashi_usr_local_repo_0.new --sparse --ignore-failed-read --tota ls . That was the command that Amanda executed. sendsize[18503]: time 0.008: waiting for any estimate child: 1 running sendsize[18505]: time 0.148: /bin/gtar: ./xxx/__db.003: Warning: Cannot seek to 0: Bad file descriptor And gtar complains with the above error message. Any ideas why this is so and what I should do about it? What happens if you run that command by hand, as root? You may even remove the --listed-incremental /usr/local/ option from the cmd line, or replace the arg with /dev/null. Also, older versions of gnutar had bugs in handling sparse files. Are you sure have a good gnutar version? (1.15.1 is OK, as wel as Redhat 1.14 with backported patches e.g. tar-1.14-9.RHEL4 rpm package.) -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Cannot seek to 0: Bad file descriptor
Thank you for the tips. Reply inline. On Tue, 2006-04-04 at 11:33 +0200, Paul Bijnens wrote: On 2006-04-04 10:48, David Leangen wrote: sendsize: debug 1 pid 18503 ruid 503 euid 503: start at Tue Apr 4 sendsize[18505]: argument list: /bin/gtar --create --file /dev/null --directory /usr/local/repo --one-file-system --list ed-incremental /usr/local/var/amanda/gnutar-lists/shinsaibashi_usr_local_repo_0.new --sparse --ignore-failed-read --tota ls . That was the command that Amanda executed. What happens if you run that command by hand, as root? [EMAIL PROTECTED] amanda]# /bin/gtar --create --file /dev/null --directory /usr/local/repo --one-file-system --listed-incremental /dev/null --sparse --ignore-failed-read --totals . /bin/gtar: ./xxx/db/__db.003: Warning: Cannot seek to 0: Bad file descriptor /bin/gtar: ./xxx/db/__db.004: Warning: Cannot seek to 0: Bad file descriptor /bin/gtar: ./xxx/db/__db.001: Warning: Cannot seek to 0: Bad file descriptor Here is an ls of files that are listed in this problem (only the __db.00xx files): total 1508 drwxrws--- 2 subversion subversion 4096 Feb 6 20:19 . drwxrwx--- 7 subversion subversion 4096 Feb 6 20:20 .. -rw-rw 1 subversion subversion 8192 Mar 28 13:07 changes -rw-rw 1 subversion subversion 8192 Mar 28 13:07 copies -rw-rw 1 subversion subversion 16384 Feb 6 20:19 __db.001 -rw-rw 1 subversion subversion 278528 Feb 6 20:19 __db.002 -rw-rw 1 subversion subversion 327680 Feb 6 20:19 __db.003 -rw-rw 1 subversion subversion 892928 Feb 6 20:19 __db.004 -rw-rw 1 subversion subversion 16384 Feb 6 20:19 __db.005 -rw-rw 1 subversion subversion 1738 Feb 6 20:19 DB_CONFIG -rw-rw 1 subversion subversion 4 Feb 6 20:19 fs-type -rw-rw 1 subversion subversion 592391 Mar 28 13:07 log.01 -rw-rw 1 subversion subversion 8192 Mar 28 13:07 nodes -rw-rw 1 subversion subversion 8192 Mar 28 13:07 representations -rw-rw 1 subversion subversion 8192 Mar 28 13:07 revisions -rw-rw 1 subversion subversion 32768 Mar 28 13:07 strings -rw-rw 1 subversion subversion 8192 Mar 28 13:07 transactions -rw-rw 1 subversion subversion 8192 Mar 28 13:07 uuids Also, older versions of gnutar had bugs in handling sparse files. Are you sure have a good gnutar version? (1.15.1 is OK, as wel as Redhat 1.14 with backported patches e.g. tar-1.14-9.RHEL4 rpm package.) Version seems fine: [EMAIL PROTECTED] amanda]# tar --version tar (GNU tar) 1.15.1 Thanks!
Re: Cannot seek to 0: Bad file descriptor
On 2006-04-04 11:48, David Leangen wrote: [EMAIL PROTECTED] amanda]# /bin/gtar --create --file /dev/null --directory /usr/local/repo --one-file-system --listed-incremental /dev/null --sparse --ignore-failed-read --totals . /bin/gtar: ./xxx/db/__db.003: Warning: Cannot seek to 0: Bad file descriptor /bin/gtar: ./xxx/db/__db.004: Warning: Cannot seek to 0: Bad file descriptor /bin/gtar: ./xxx/db/__db.001: Warning: Cannot seek to 0: Bad file descriptor Having a closer look at my own installation, I see that I have the same warning. It has indeed to do with the combination of sparse file handling and output in /dev/null. Moreover, with --ignore-failed-read, the exit status is 0, all OK. I still believe that is a bug in gnutar, but not critical. When doing the backup itself (sendbackup, not sendsize) the output is not to /dev/null, and the warning goes away too. See also: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154882 So this is not the cause of your trouble. What exactly is the error message that you get for those clients? -- Paul Bijnens, xplanation Technology ServicesTel +32 16 397.511 Technologielaan 21 bus 2, B-3001 Leuven, BELGIUMFax +32 16 397.512 http://www.xplanation.com/ email: [EMAIL PROTECTED] *** * I think I've got the hang of it now: exit, ^D, ^C, ^\, ^Z, ^Q, ^^, * * F6, quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, bye, /bye, * * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, abort, hangup, * * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, shutdown, * * init 0, kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, Stop-A, ... * * ... Are you sure? ... YES ... Phew ... I'm out * ***
Re: Cannot seek to 0: Bad file descriptor
So this is not the cause of your trouble. What exactly is the error message that you get for those clients? Hmmm... To recap the problem: backups from my networked machines are not being received by my amanda host since I've updated. I'll dig a bit deeper to see if I can see anything else unusual. Thanks for the help so far! I'll be back if I can't find anything else. Thanks again!
Re: Bad file descriptor ??
On Tue, 14 Jan 2003 at 12:22pm, Marcel Welschbillig wrote Hi all, Hi. Please don't send HTML as well as plain text -- there's really no point to it. Just use plain text. I've been using Amanda to backup some Linux systems for quite some time. Recently I am getting the following errors. FAILURE AND STRANGE DUMP SUMMARY: eth0.yeast sda3 lev 0 FAILED [closing tape: Input/output error] eth0.yeast sda3 lev 0 FAILED [dump to tape failed] eth0.yeast sda2 lev 0 FAILED [closing tape: Bad file descriptor] eth0.yeast sda2 lev 0 FAILED [dump to tape failed] barley sda5 lev 0 FAILED [closing tape: Bad file descriptor] barley sda5 lev 0 FAILED [dump to tape failed] On Barley it has no problem backing up other partitions only sda5 which is the /home directory. It backs up many other servers with no problems, only has problems on barley and yeast. I'm assuming there are some corrupt files that can not be read on these partitions, how do I find them and repair/delete them?? There should be details of the FAILED dumps further down in the email. Also, look in /tmp/amanda/sendbackup*debug on eth0 and barley. -- Joshua Baker-LePain Department of Biomedical Engineering Duke University
RE: Bad file descriptor ??
Thnaks for the response. Sorry, will post in Plain text.
This is the file /tmp/amanda/sendbackup.debug
sendbackup: debug 1 pid 10346 ruid 530 euid 530 start time Tue Jan 14
11:28:54 2003
/usr/lib/amanda/sendbackup: got input request: DUMP sda5 0
1970:1:1:0:0:0
OPTIONS |;bsd-auth;compress-fast;
parsed request as: program `DUMP' disk `sda5' lev 0 since
1970:1:1:0:0:0
opt `|;bsd-auth;compress-fast;'
waiting for connect on 2340, then 2341
got all connections
sendbackup: spawning /bin/gzip in pipeline
sendbackup: argument list: /bin/gzip --fast
sendbackup: spawning /sbin/dump in pipeline
sendbackup: argument list: dump 0usf 1048576 - /dev/sda5
Still gives me no clue whats going wrong though, any ideas ??
Also below are some things that may be relevent from the rest of the
backup report, dosent tell me which file is failing though.
STATISTICS:
Total Full Daily
Dump Time (hrs:min) 34:19 3:09 0:00 (0:09 start,
31:01 idle)
Output Size (meg)3910.5 3910.50.0
Original Size (meg) 9391.7 9391.70.0
Avg Compressed Size (%)41.6 41.6--
Tape Used (%) 32.6 32.60.0
Filesystems Dumped 40 40 0
Avg Dump Rate (k/s) 355.5 355.5--
Avg Tp Write Rate (k/s) 353.4 353.4--
NOTES:
planner: Last full dump of barley:sda1 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda5 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda6 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda7 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda8 on tape Comdek1 overwritten on
this run.
planner: Last full dump of eth0.yeast:sda2 on tape Comdek1 overwritten
on this run.
n this run.
planner: Last full dump of barley:sda1 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda5 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda6 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda7 on tape Comdek1 overwritten on
this run.
planner: Last full dump of barley:sda8 on tape Comdek1 overwritten on
this run.
planner: Last full dump of eth0.yeast:sda2 on tape Comdek1 overwritten
on this run.
taper: tape Comdek1 kb 2136096 fm 21 writing file: Input/output error
taper: tape Comdek1 kb 2136096 fm 21 writing filemark: Bad file
descriptor
taper: tape Comdek1 kb 2136096 fm 21 writing filemark: Bad file
descriptor
taper: tape Comdek1 kb 2136096 fm 21 [OK]
DUMP SUMMARY:
DUMPER STATS
TAPER STATS
HOSTNAME DISK L ORIG-KB OUT-KB COMP% MMM:SS KB/s
MMM:SS KB/s
-- --
--
barleysda1 03943413440 34.10:34 399.6
0:35 383.2
barleysda5 0 FAILED
barleysda6 0 393225 151968 38.64:34 553.8
4:35 553.0
barleysda7 0 2831 992 35.00:05 208.8
0:05 202.9
barleysda8 0 499372 204032 40.96:47 500.9
6:48 499.6
comdek-ra hda2 0 286333 104032 36.34:24 393.9
4:25 393.0
comdek-ra hda3 0 10878586048 79.12:49 510.3
2:49 509.0
eth0.yeas sda2 0 FAILED
eth0.yeas sda3 0 FAILED
hops sda1 03778513120 34.70:22 584.2
0:23 564.6
hops sda5 0 687518 489984 71.3 41:26 197.1
41:27 197.0
hops sda6 0 2608 960 36.80:05 197.7
0:15 66.6
hops sda8 0 375362 143552 38.24:37 519.0
4:38 516.8
hops sda9 0 16425121280 13.02:17 155.1
2:18 154.5
localhost hda2 0 22892791936 40.28:05 189.4
8:06 189.2
localhost hda3 0 18437629920 16.26:04 82.3
6:04 82.2
malt sda1 0 270261 202112 74.86:20 531.5
6:22 529.3
malt sda5 0 410510 157056 38.35:50 448.9
5:51 447.0
malt sda7 0 29614941664 14.12:07 327.5
2:08 324.7
malt sda8 0 143 32 22.40:122.6
0:144.6
proxy.con hda1 0 295008 112960 38.34:16 442.0
4:16 440.8
proxy.con hda2 09916748768 49.21:50 441.3
1:51 438.2
sugar sda2 0 426504 186240 43.79:40 321.2
9:43 319.6
(brought to you by Amanda version 2.4.0)
Marcel
-Original Message-
From: Joshua Baker-LePain [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, 14 January 2003 7:54 PM
To: Marcel Welschbillig
Cc: [EMAIL PROTECTED]
Subject: Re
Bad file descriptor ??
Hi all, Ive been using Amanda to backup some Linux systems for quite some time. Recently I am getting the following errors. FAILURE AND STRANGE DUMP SUMMARY: eth0.yeast sda3 lev 0 FAILED [closing tape: Input/output error] eth0.yeast sda3 lev 0 FAILED [dump to tape failed] eth0.yeast sda2 lev 0 FAILED [closing tape: Bad file descriptor] eth0.yeast sda2 lev 0 FAILED [dump to tape failed] barley sda5 lev 0 FAILED [closing tape: Bad file descriptor] barley sda5 lev 0 FAILED [dump to tape failed] On Barley it has no problem backing up other partitions only sda5 which is the /home directory. It backs up many other servers with no problems, only has problems on barley and yeast. Im assuming there are some corrupt files that can not be read on these partitions, how do I find them and repair/delete them?? Thanks in advance ! Marcel
Re: Bad file descriptor
Every day now (for the past 3 days) I have been getting the same errors: Bad file descriptor Sigh. Amanda is not telling you the whole story there (can't remember if this is fixed in the current source or not). Here is the real culprit from the NOTES section: taper: tape Daily3 kb 96890112 fm 22 writing file: No space left on device That no space left on device usually translates to you just hit end of tape. Note that you wrote just under 100 GBytes. Does that roughly match the tape size you expect? Dick Kreutzer John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: Bad file descriptor
On Wed, Mar 13, 2002 at 07:59:02PM -0500, John R. Jackson wrote: Every day now (for the past 3 days) I have been getting the same errors: Bad file descriptor Sigh. Amanda is not telling you the whole story there (can't remember if this is fixed in the current source or not). It's not, this patch should fix it. Or maybe just set degraded_mode to 1. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834 --- server-src/driver.c.1 Wed Mar 13 18:34:12 2002 +++ server-src/driver.c Thu Mar 14 09:57:30 2002 @@ -2189,6 +2189,7 @@ update_failed_dump_to_tape(dp); free_serial(result_argv[2]); failed = 2; /* fatal problem */ + start_degraded_mode(runq); } /* reset statistics return */
Bad file descriptor
Dear Amanda Users,
I continue to have the problems listed below in the log. I have
specified a tapetype length of 4 meg (while the tape is advertised
at 66000 meg) but I still get out of tape in addition to Bad file
descriptor which I was tole in a previous reply is related to hitting
EOT.
I also assume the data write: Broken pipe is due to the out of tape
error.
What do I need to do to keep amanda from trying to put more on a tape
than will fit.
Thanks,
Dick
These dumps were to tape Daily4.
*** A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: Daily5.
FAILURE AND STRANGE DUMP SUMMARY:
vulcan.int /usr lev 0 FAILED [out of tape]
vulcan.int /usr lev 0 FAILED [data write: Broken pipe]
vulcan.int /usr lev 0 FAILED [dump to tape failed]
gorn.ameri / lev 0 FAILED [out of tape]
gorn.ameri / lev 0 FAILED [data write: Broken pipe]
gorn.ameri / lev 0 FAILED [dump to tape failed]
andorian.a / lev 0 FAILED [out of tape]
andorian.a / lev 0 FAILED [data write: Broken pipe]
andorian.a / lev 0 FAILED [dump to tape failed]
solo.ameri /idebigger lev 0 FAILED [out of tape]
solo.ameri /idebigger lev 0 FAILED [data write: Broken pipe]
solo.ameri /idebigger lev 0 FAILED [dump to tape failed]
maul.ameri / lev 0 FAILED [out of tape]
maul.ameri / lev 0 FAILED [data write: Broken pipe]
maul.ameri / lev 0 FAILED [dump to tape failed]
gorn.ameri /ideroot2 lev 0 FAILED [out of tape]
gorn.ameri /ideroot2 lev 0 FAILED [data write: Broken pipe]
gorn.ameri /ideroot2 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:04
Run Time (hrs:min) 6:34
Dump Time (hrs:min)0:18 0:00 0:18
Output Size (meg)2164.60.0 2164.6
Original Size (meg) 2164.60.0 2164.6
Avg Compressed Size (%) -- -- --(level:#disks ...)
Filesystems Dumped 19 0 19 (1:19)
Avg Dump Rate (k/s) 2063.4-- 2063.4
Tape Time (hrs:min)0:16 0:00 0:16
Tape Size (meg) 2165.20.0 2165.2
Tape Used (%) 5.50.05.5 (level:#disks ...)
Filesystems Taped19 0 19 (1:19)
Avg Tp Write Rate (k/s) 2298.3-- 2298.3
FAILED AND STRANGE DUMP DETAILS:
/-- vulcan.int /usr lev 0 FAILED [data write: Broken pipe]
sendbackup: start [vulcan.internal.americom.com:/usr level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/sbin/restore -f... -
sendbackup: info end
| DUMP: Date of this level 0 dump: Thu Mar 14 06:21:39 2002
| DUMP: Dumping /dev/hda2 (/usr) to standard output
| DUMP: Exclude ext3 journal inode 8
| DUMP: Label: /usr
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 3236344 tape blocks.
| DUMP: Volume 1 started with block 1 at: Thu Mar 14 06:22:06 2002
| DUMP: dumping (Pass III) [directories]
| DUMP: dumping (Pass IV) [regular files]
| DUMP: 32.56% done at 3512 kB/s, finished in 0:10
| DUMP: 78.77% done at 4249 kB/s, finished in 0:02
| DUMP: 100.00% done at 4494 kB/s, finished in 0:00
| DUMP: 100.00% done at 4617 kB/s, finished in 0:00
| DUMP: 100.00% done at 4691 kB/s, finished in 0:00
| DUMP: 100.00% done at 4740 kB/s, finished in 0:00
| DUMP: 100.00% done at 4774 kB/s, finished in 0:00
| DUMP: 100.00% done at 4801 kB/s, finished in 0:00
| DUMP: 100.00% done at 4821 kB/s, finished in 0:00
| DUMP: 100.00% done at 4837 kB/s, finished in 0:00
| DUMP: 100.00% done at 4851 kB/s, finished in 0:00
| DUMP: 100.00% done at 4854 kB/s, finished in 0:00
| DUMP: 100.00% done at 4859 kB/s, finished in 0:00
| DUMP: 100.00% done at 4868 kB/s, finished in 0:00
| DUMP: 100.00% done at 4876 kB/s, finished in 0:00
| DUMP: 100.00% done at 4883 kB/s, finished in 0:00
| DUMP: 100.00% done at 4889 kB/s, finished in 0:00
| DUMP: 100.00% done at 4894 kB/s, finished in 0:00
| DUMP: 100.00% done at 4899 kB/s, finished in 0:00
| DUMP: 100.00% done at 4904 kB/s, finished in 0:00
| DUMP: 100.00% done at 4908 kB/s, finished in 0:00
| DUMP: 100.00% done at 4912 kB/s, finished in 0:00
| DUMP: 100.00% done at 4915 kB/s, finished in 0:00
| DUMP: 100.00% done at 4914 kB/s, finished in 0:00
| DUMP: 100.00% done at 4917 kB/s, finished in 0:00
| DUMP: 100.00% done at 4920 kB/s, finished in 0:00
| DUMP: 100.00% done at 4923 kB/s, finished in 0:00
| DUMP: 100.00% done at 4926 kB/s, finished in 0:00
| DUMP: 100.00% done at 4928 kB/s, finished in 0:00
| DUMP: 100.00% done at 4930 kB/s, finished in 0:00
| DUMP: 100.00% done at 4932 kB/s, finished in 0:00
| DUMP: 100.00% done at 4934 kB/s, finished in 0:00
| DUMP: 100.00% done
Bad file descriptor
Dear Amanda Users,
Every day now (for the past 3 days) I have been getting the same errors:
Bad file descriptor
I have included the summary report below.
Can anyone suggest what is wrong?
Thanks,
Dick Kreutzer
AmeriCom Inc.
These dumps were to tape Daily3.
*** A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: Daily4.
FAILURE AND STRANGE DUMP SUMMARY:
vulcan.int /usr lev 0 FAILED [data timeout]
vulcan.int /usr lev 0 FAILED [dump to tape failed]
andorian.a / lev 0 FAILED [out of tape]
andorian.a / lev 0 FAILED [data write: Broken pipe]
andorian.a / lev 0 FAILED [dump to tape failed]
solo.ameri /idebigger lev 0 FAILED [out of tape]
solo.ameri /idebigger lev 0 FAILED [data write: Broken pipe]
solo.ameri /idebigger lev 0 FAILED [dump to tape failed]
maul.ameri / lev 0 FAILED [out of tape]
maul.ameri / lev 0 FAILED [data write: Broken pipe]
maul.ameri / lev 0 FAILED [dump to tape failed]
gorn.ameri /ideroot2 lev 0 FAILED [out of tape]
gorn.ameri /ideroot2 lev 0 FAILED [data write: Broken pipe]
gorn.ameri /ideroot2 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:04
Run Time (hrs:min) 6:28
Dump Time (hrs:min)0:50 0:35 0:16
Output Size (meg)9555.0 7905.6 1649.5
Original Size (meg) 9555.0 7905.6 1649.5
Avg Compressed Size (%) -- -- --(level:#disks ...)
Filesystems Dumped 20 4 16 (1:15 2:1)
Avg Dump Rate (k/s) 3253.2 3904.9 1807.5
Tape Time (hrs:min)5:54 5:40 0:14
Tape Size (meg) 89474.287824.2 1650.0
Tape Used (%) 223.8 219.64.2 (level:#disks ...)
Filesystems Taped21 5 16 (1:15 2:1)
Avg Tp Write Rate (k/s) 4313.3 4411.6 1973.5
FAILED AND STRANGE DUMP DETAILS:
/-- vulcan.int /usr lev 0 FAILED [data timeout]
sendbackup: start [vulcan.internal.americom.com:/usr level 0]
sendbackup: info BACKUP=/sbin/dump
sendbackup: info RECOVER_CMD=/sbin/restore -f... -
sendbackup: info end
| DUMP: Date of this level 0 dump: Wed Mar 13 06:23:12 2002
| DUMP: Dumping /dev/hda2 (/usr) to standard output
| DUMP: Exclude ext3 journal inode 8
| DUMP: Label: /usr
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 3148496 tape blocks.
| DUMP: Volume 1 started with block 1 at: Wed Mar 13 06:23:38 2002
| DUMP: dumping (Pass III) [directories]
| DUMP: dumping (Pass IV) [regular files]
| DUMP: 33.91% done at 3558 kB/s, finished in 0:09
| DUMP: 81.40% done at 4271 kB/s, finished in 0:02
| DUMP: 100.00% done at 4509 kB/s, finished in 0:00
| DUMP: 100.00% done at 4627 kB/s, finished in 0:00
| DUMP: 100.00% done at 4699 kB/s, finished in 0:00
| DUMP: 100.00% done at 4747 kB/s, finished in 0:00
| DUMP: 100.00% done at 4780 kB/s, finished in 0:00
| DUMP: 100.00% done at 4806 kB/s, finished in 0:00
| DUMP: 100.00% done at 4826 kB/s, finished in 0:00
| DUMP: 100.00% done at 4842 kB/s, finished in 0:00
| DUMP: 100.00% done at 4855 kB/s, finished in 0:00
| DUMP: 100.00% done at 4855 kB/s, finished in 0:00
| DUMP: 100.00% done at 4866 kB/s, finished in 0:00
| DUMP: 100.00% done at 4875 kB/s, finished in 0:00
| DUMP: 100.00% done at 4884 kB/s, finished in 0:00
| DUMP: 100.00% done at 4891 kB/s, finished in 0:00
| DUMP: 100.00% done at 4897 kB/s, finished in 0:00
| DUMP: 100.00% done at 4903 kB/s, finished in 0:00
| DUMP: 100.00% done at 4908 kB/s, finished in 0:00
| DUMP: 100.00% done at 4913 kB/s, finished in 0:00
| DUMP: 100.00% done at 4917 kB/s, finished in 0:00
| DUMP: 100.00% done at 4920 kB/s, finished in 0:00
| DUMP: 100.00% done at 4924 kB/s, finished in 0:00
| DUMP: 100.00% done at 4923 kB/s, finished in 0:00
| DUMP: 100.00% done at 4925 kB/s, finished in 0:00
| DUMP: 100.00% done at 4927 kB/s, finished in 0:00
| DUMP: 100.00% done at 4930 kB/s, finished in 0:00
| DUMP: 100.00% done at 4932 kB/s, finished in 0:00
| DUMP: 100.00% done at 4933 kB/s, finished in 0:00
| DUMP: 100.00% done at 4935 kB/s, finished in 0:00
| DUMP: 100.00% done at 4937 kB/s, finished in 0:00
| DUMP: 100.00% done at 4938 kB/s, finished in 0:00
| DUMP: 100.00% done at 4940 kB/s, finished in 0:00
| DUMP: 100.00% done at 4941 kB/s, finished in 0:00
| DUMP: 100.00% done at 4939 kB/s, finished in 0:00
| DUMP: 100.00% done at 4941 kB/s, finished in 0:00
| DUMP: 100.00% done at 4943 kB/s, finished in 0:00
| DUMP: 100.00% done at 4944 kB/s, finished in 0:00
| DUMP: 100.00% done at 4945 kB/s, finished in 0:00
| DUMP: 100.00% done at 4946 kB/s, finished in 0:00
| DUMP: 100.00% done at 4947 kB/s
Re: Bad file descriptor
Every day now (for the past 3 days) I have been getting the same errors: Bad file descriptor Sigh. Amanda is not telling you the whole story there (can't remember if this is fixed in the current source or not). Here is the real culprit from the NOTES section: taper: tape Daily3 kb 96890112 fm 22 writing file: No space left on device That no space left on device usually translates to you just hit end of tape. Note that you wrote just under 100 GBytes. Does that roughly match the tape size you expect? Yes (assuming you mean uncompressed). I have the VXA-1 V17 tapetype set at 40G. It is rated at 66G. It uses hardware compression. I am actually surprised it hits end-of-tape with my 40G estimate. I have lowered the tapetype length from 50G to 40G and I still hit EOT. Please clarify for me: . Does amanda try to limit what it puts on a tape to what it thinks will fit? In my case to 40G? ...based on the estimates phase? What should I do to avoid hitting EOT? I don't like to have to manually flush files. Thanks, Dick
Re: A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
Olivier Nicole wrote: tapetype: could not rewind /dev/nst0: Input/output error Did you run tapetype as root? Yes. And mt -f /dev/nst0 rewind works prefect. Sven
Re: A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
Alexandre Oliva wrote:
/-- localhost /dev/md190 lev 1 FAILED [data write: Broken pipe]
What does that mean? Is my tape broken?
It probably means you ran out of tape space during a direct-to-tape
backup.
I don't think that was the problem because I have a DDS-3 tape and amanda
used only:
Output Size (meg) 1.10.01.1
I'v never seen this under NOTES:
NOTES:
taper: tape daily26 kb 0 fm 0 writing filemark: Input/output error
Sven
--
I attach the whole report:
These dumps were to tape daily26.
*** A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]].
Some dumps may have been left in the holding disk.
Run amflush to flush them to tape.
The next tape Amanda expects to use is: daily27.
FAILURE AND STRANGE DUMP SUMMARY:
localhost /dev/md191 lev 1 FAILED [out of tape]
localhost /dev/md191 lev 1 FAILED [dump to tape failed]
localhost /dev/md230 lev 1 FAILED [out of tape]
localhost /dev/md230 lev 1 FAILED [dump to tape failed]
localhost /dev/md192 lev 1 FAILED [out of tape]
localhost /dev/md192 lev 1 FAILED [dump to tape failed]
localhost /dev/md101 lev 1 FAILED [out of tape]
localhost /dev/md101 lev 1 FAILED [dump to tape failed]
localhost /dev/md220 lev 1 FAILED [out of tape]
localhost /dev/md220 lev 1 FAILED [dump to tape failed]
localhost /dev/md100 lev 1 FAILED [out of tape]
localhost /dev/md100 lev 1 FAILED [dump to tape failed]
localhost /dev/md190 lev 1 FAILED [out of tape]
localhost /dev/md190 lev 1 FAILED [data write: Broken pipe]
localhost /dev/md190 lev 1 FAILED [dump to tape failed]
localhost /dev/md199 lev 1 FAILED [out of tape]
localhost /dev/md199 lev 1 FAILED [data write: Broken pipe]
localhost /dev/md199 lev 1 FAILED [dump to tape failed]
localhost /dev/md151 lev 1 FAILED [out of tape]
localhost /dev/md151 lev 1 FAILED [data write: Broken pipe]
localhost /dev/md151 lev 1 FAILED [dump to tape failed]
localhost /dev/md251 lev 1 FAILED [out of tape]
localhost /dev/md251 lev 1 FAILED [data write: Broken pipe]
localhost /dev/md251 lev 1 FAILED [dump to tape failed]
localhost /dev/md200 lev 1 FAILED [out of tape]
localhost /dev/md200 lev 1 FAILED [data write: Broken pipe]
localhost /dev/md200 lev 1 FAILED [dump to tape failed]
localhost /dev/md150 lev 0 FAILED [out of tape]
localhost /dev/md150 lev 0 FAILED [data write: Broken pipe]
localhost /dev/md150 lev 0 FAILED [dump to tape failed]
localhost /dev/md159 lev 1 FAILED [out of tape]
localhost /dev/md159 lev 1 FAILED [data write: Broken pipe]
localhost /dev/md159 lev 1 FAILED [dump to tape failed]
localhost /dev/md170 lev 0 FAILED [out of tape]
localhost /dev/md170 lev 0 FAILED [data write: Broken pipe]
localhost /dev/md170 lev 0 FAILED [dump to tape failed]
localhost /dev/md210 lev 0 FAILED [out of tape]
localhost /dev/md210 lev 0 FAILED [data write: Broken pipe]
localhost /dev/md210 lev 0 FAILED [dump to tape failed]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)2:08
Run Time (hrs:min) 2:50
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 1.10.01.1
Original Size (meg) 1.10.01.1
Avg Compressed Size (%) -- -- --(level:#disks ...)
Filesystems Dumped6 0 6 (1:6)
Avg Dump Rate (k/s) 200.3-- 200.3
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
FAILED AND STRANGE DUMP DETAILS:
/-- localhost /dev/md190 lev 1 FAILED [data write: Broken pipe]
sendbackup: start [localhost:/dev/md190 level 1]
sendbackup: info BACKUP=/opt/tar-1.13.19/bin/tar
sendbackup: info RECOVER_CMD=/opt/tar-1.13.19/bin/tar -f... -
sendbackup: info end
\
/-- localhost /dev/md199 lev 1 FAILED [data write: Broken pipe]
sendbackup: start [localhost:/dev/md199 level 1]
sendbackup: info BACKUP=/opt/tar-1.13.19/bin/tar
sendbackup: info RECOVER_CMD=/opt/tar-1.13.19/bin/tar -f... -
sendbackup: info end
\
/-- localhost /dev/md151 lev 1 FAILED [data write: Broken pipe]
sendbackup: start [localhost:/dev/md151 level 1]
sendbackup: info BACKUP=/opt/tar-1.13.19/bin/tar
sendbackup: info RECOVER_CMD=/opt/tar-1.13.19/bin/tar -f... -
sendbackup: info end
\
/-- localhost /dev/md251 lev 1 FAILED [data write: Broken pipe]
sendbackup: start [localhost:/dev/md251 level 1]
sendbackup: info BACKUP=/opt/tar-1.13.19/bin/tar
sendbackup: info RECOVER_CMD=/opt/tar-1.13.19/bin/tar -f... -
sendbackup: info end
\
/-- localhost /dev/md200 lev 1 FAILED [data write: Broken pipe]
sendbackup: start [localhost:/dev/md200
Re: A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
NOTES: taper: tape daily26 kb 0 fm 0 writing filemark: Input/output error Sory for replaying to my own message. I found something in syslog: kernel: st0: Error with sense data: Info fld=0x1, Current st 09:00: sense key Medium Error kernel: Additional sense indicates Write error I think that means the tape is broken...? Sven
Re: A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
Alexandre Oliva wrote: I think that means the tape is broken...? Quite possibly. Try running tapetype on it and see how far it goes. tapetype did not complain but it found 44235 mbytes on a DDS3 (without hw compression). And I got a tapetype: could not rewind /dev/nst0: Input/output error Sven
Re: A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
tapetype did not complain but it found 44235 mbytes on a DDS3 (without hw compression). And I got a Tell me the trick you did with your drive to store 44 GB on a DDS-3 tape! ;-) You should get something around 11.900 MB without and 9.500 MB with hardware compression (yes, random data (i.e. gzipped data) is blown up by h/w compression). I assume you got faulty hardware.
Re: A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
tapetype: could not rewind /dev/nst0: Input/output error Did you run tapetype as root? Olivier
A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]
I got the following error: -- These dumps were to tape daily26. *** A TAPE ERROR OCCURRED: [[writing file: Bad file descriptor]]. Some dumps may have been left in the holding disk. Run amflush to flush them to tape. The next tape Amanda expects to use is: daily27. [snip] FAILED AND STRANGE DUMP DETAILS: /-- localhost /dev/md190 lev 1 FAILED [data write: Broken pipe] sendbackup: start [localhost:/dev/md190 level 1] sendbackup: info BACKUP=/opt/tar-1.13.19/bin/tar sendbackup: info RECOVER_CMD=/opt/tar-1.13.19/bin/tar -f... - sendbackup: info end \ -- What does that mean? Is my tape broken? And amflush does not work: amanda@# sbin/amflush daily Could not find any Amanda directories to flush. Is that because I do not have a holding disk? Sven
