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
,
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
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.
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
: 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
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
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
/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
: ./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
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
]# /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.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
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
.
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
.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
.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
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
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
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
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
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
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
: [[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
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
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
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.
tapetype: could not rewind /dev/nst0: Input/output error
Did you run tapetype as root?
Olivier
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
28 matches
Mail list logo
