On Mon, Jun 15, 2020 at 00:20:25 -0400, Nathan Stratton Treadway wrote:
> On Mon, Jun 15, 2020 at 10:41:58 +0700, Olivier wrote:
> > I have an Amanda client that takes more than 4 hours to do the
> > estimate. The estimate is computed correctly, but when amandad on the
[...]
> Sounds like you
I kind of remember that there is a timeout parameter that I need to
> tweak before recompiling Amanda, but I can't remember if it is on the
> client or on te server. I tend to think it is on the server. But
> definitive answer is welcome.
Sounds like you are looking for the "et
Hi,
I have an Amanda client that takes more than 4 hours to do the
estimate. The estimate is computed correctly, but when amandad on the
client tries to send back the estimate to the server, the packet times
out.
I kind of remember that there is a timeout parameter that I need to
tweak before
On Tue, May 28, 2019 at 12:57:18PM +1000, Tom Robinson wrote:
> On Tue, 14 May 2019 at 22:14, Nathan Stratton Treadway
> wrote:
>
> Hi Nathan,
>
> Thanks for you reply and help.
>
> On Mon, May 13, 2019 at 09:59:13 +1000, Tom Robinson wrote:
.
>
> I am getting a new issue now which is
t;
> > I can't seem to identify the error when looking in logging. Has anyone a
> few clues as to what to
> > look for?
> >
> > FAILURE DUMP SUMMARY:
> > monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [data
> timeout]
> > monza /data/backup/am
clues as to what to
> look for?
>
> FAILURE DUMP SUMMARY:
> monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [data timeout]
> monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [dumper returned
> FAILED]
> monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAI
anyone a few
clues as to what to
look for?
FAILURE DUMP SUMMARY:
monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [data timeout]
monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [dumper returned
FAILED]
monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [data timeout
gt;
> Wed Jul 18 04:07:18 2018: amandad:
> /opt/amanda-3.3.0/libexec/amanda/sendsize timed out waiting for REP data
> Wed Jul 18 04:07:18 2018: amandad: sending NAK pkt:
> <<<<<
> ERROR timeout on reply pipe
> >>>>>
>
> I notice the exact 6
018: amandad: sending PREP pkt:
<<<<<
OPTIONS features=9efefbff0f;
>>>>>
Wed Jul 18 04:07:18 2018: amandad:
/opt/amanda-3.3.0/libexec/amanda/sendsize timed out waiting for REP data
Wed Jul 18 04:07:18 2018: amandad: sending NAK pkt:
<<<<<
ER
2018: amandad:
> /opt/amanda-3.3.0/libexec/amanda/sendsize timed out waiting for REP data
> Wed Jul 18 04:07:18 2018: amandad: sending NAK pkt:
> <<<<<
> ERROR timeout on reply pipe
> >>>>>
>
> I notice the exact 6 hours between sending the PREP pkt
from itself):
FAILURE DUMP SUMMARY:
planner: ERROR Request to sbox.slsware.net failed: timeout waiting
for ACK
sbox.slsware.net / lev 0 FAILED [Request to sbox.slsware.net
failed: timeout waiting for ACK]
sbox.slsware.net /opt lev 0 FAILED
[Request to sbox.slsware.net failed: timeout
On Saturday 01 August 2015 08:43:24 Gene Heskett wrote:
I forgot to send this at 4:30 am.
It just got done, and the emailed report says the estimate time for a
50 gigabyte backup, was 3 minutes. Total elapsed time a hair over 3
hours.
Cheers, Gene Heskett
Humm, setting that option
On Saturday 01 August 2015 08:43:24 Gene Heskett wrote:
I forgot to send this at 4:30 am.
It just got done, and the emailed report says the estimate time for a
50 gigabyte backup, was 3 minutes. Total elapsed time a hair over 3
hours.
Cheers, Gene Heskett
3 days of uptime, and this machine
this, bit me on the 3rd day of uptime the rest
of this machine is running nominally.
Cheers, Gene Heskett
And the great Gene's saga of timeout on reply pipe continues, amdump
did a level 0 on all but 7 dle's out of 52, but even that was less than
1 vtape used. And it took 1:04 elapsed time
I forgot to send this at 4:30 am.
It just got done, and the emailed report says the estimate time for a 50
gigabyte backup, was 3 minutes. Total elapsed time a hair over 3 hours.
Cheers, Gene Heskett
--
There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo.
On Fri, Jul 31, 2015 at 10:38:54PM -0400, Gene Heskett wrote:
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over
On Saturday 01 August 2015 03:26:55 Jon LaBadie wrote:
On Fri, Jul 31, 2015 at 10:38:54PM -0400, Gene Heskett wrote:
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
On Saturday 01 August 2015 03:59:28 Gene Heskett wrote:
On Saturday 01 August 2015 03:26:55 Jon LaBadie wrote:
On Fri, Jul 31, 2015 at 10:38:54PM -0400, Gene Heskett wrote:
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5 always
work.
And it failed last night again, after only 3 days uptime. and only this
machine. From an amcheck and GO704 is turned off:
Grr! My etimeout is 2000 but yours is certainly in that ball park.
I’d try it at 20,000 (without the comma) just to see if it changes anything.
For a while.
Although, I guess “waiting forever” is what it is currently already
doing, isn’t it?
Hmmm. Thinking.
Deb Baddorf
On Jul
Back on the list, this server aparently does not set a reply-to. So a
reply to list comes up with a blank To: address line.
On Friday 31 July 2015 12:21:39 Debra S Baddorf wrote:
Grr! My etimeout is 2000 but yours is certainly in that ball
park. I’d try it at 20,000 (without the comma)
Gene: Have you seen these additional debug parameters? There may be even more
than these. This is the list that seemed useful to me, when I pulled them.
They go in the amanda.conf
file. They can produce a huge log file, but perhaps it might say more?
## temp settings 4/3/13 dsb
On Friday 31 July 2015 17:06:30 Jon LaBadie wrote:
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5
always work.
etimeout was 600, made it 1800
On Friday 31 July 2015 17:14:19 Debra S Baddorf wrote:
Gene: Have you seen these additional debug parameters? There may be
even more than these. This is the list that seemed useful to me,
when I pulled them.They go in the amanda.conf file. They can
produce a huge log file, but
On Sun, Jul 19, 2015 at 04:21:29AM -0400, Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5 always
work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5 always
work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small change, 135 megs into swap on an 8Gb equipt
machine.
A reboot fixes
On Sunday 19 July 2015 04:21:29 Gene Heskett wrote:
On Saturday 18 July 2015 10:40:38 Gene Heskett wrote:
Only on THIS machine, the remotes being backed up over the cat5
always work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small change, 135
Only on THIS machine, the remotes being backed up over the cat5 always
work.
etimeout was 600, made it 1800
dtimeout was 1800, made it 2400
uptime is 7 days small change, 135 megs into swap on an 8Gb equipt
machine.
A reboot fixes it, for a few days, then once its started, only a reboot
, then probably something suddenly made it
stop working (e.g. a hung NFS mount, as Joi mentioned).
If it was just a few minutes under 6 hours, then maybe the file count
just grew enough that it tipped over the estimate timeout, in which case
bumping the timeout in the config might be enough to get things
Folks,
I have an Ubuntu 14.04 LTS system running Amanda 3.3.6 server backing up a Solaris 10 system with
Amanda 3.3.2.
I had it working and I was getting backups of that particular Solaris system. Then I suddenly
started getting the timeout on reply pipe on every single dle on that system
3.3.2.
I had it working and I was getting backups of that particular Solaris
system. Then I suddenly started getting the timeout on reply pipe on
every single dle on that system, but not on any other systems. There
is also another virtually identical Solaris system (except with Amanda
2.5.1p3
/2015 02:40 PM, Chris Hoogendyk wrote:
Folks,
I have an Ubuntu 14.04 LTS system running Amanda 3.3.6 server backing up a Solaris 10 system with
Amanda 3.3.2.
I had it working and I was getting backups of that particular Solaris system. Then I suddenly
started getting the timeout on reply pipe
happy to extend the timeout if that were the issue.
On 1/21/15 4:04 PM, Jean-Louis Martineau wrote:
The estimate took more than 6 hours!
After how much time do you get the timeout error?
What is your etimeout setting?
You could tried faster estimate method: calcsize or server.
Jean-Louis
On 01
: owner-amanda-us...@amanda.org [mailto:owner-amanda-us...@amanda.org] On
Behalf Of Chris Hoogendyk
Sent: Wednesday, January 21, 2015 15:40
To: Jean-Louis Martineau
Cc: AMANDA users
Subject: Re: amcheck 0 problems, but timeout on reply pipe
If some of the DLEs were fully estimated in short time
).
If it was just a few minutes under 6 hours, then maybe the file count
just grew enough that it tipped over the estimate timeout, in which case
bumping the timeout in the config might be enough to get things working
again with the minium of changes. (However, 6 hours seems like a long
time
On 10/14/2014 06:14 PM, Debra S Baddorf wrote:
( I’ve joined the amanda-hackers list too. Would this be better there? )
Since amanda 3.3.3 (when I started using bsdtcp and krb5 auth types, in
addition to bsd),
I’m getting a 3 minute timeout on connection to a node that is down. I’ve
to bsd),
I’m getting a 3 minute timeout on connection to a node that is down. I’ve
deduced that I
can lower “connect-tries” from the default of 3 down to 2. This reduces my
freeze time from
9 minutes to 6. I’m not sure lowering “connect-tries” to 1 is safe.
Where is the 3 minute
( I’ve joined the amanda-hackers list too. Would this be better there? )
Since amanda 3.3.3 (when I started using bsdtcp and krb5 auth types, in
addition to bsd),
I’m getting a 3 minute timeout on connection to a node that is down. I’ve
deduced that I
can lower “connect-tries” from
There is no parameter for that timeout. It is a constant in the program.
CONNECT_TIMEOUT in the server-src/chunker.c file
Running the script on the client might fix the issue
execute-where client
Even runing on the client it will take more than 300 seconds, would the
chunker wait
Olivier,
There is no parameter for that timeout. It is a constant in the program.
CONNECT_TIMEOUT in the server-src/chunker.c file
Running the script on the client might fix the issue
execute-where client
Jean-Louis
On 09/24/2014 12:04 AM, Olivier Nicole wrote:
Hi,
For one specific DLE, I
Jean-Louis,
There is no parameter for that timeout. It is a constant in the program.
CONNECT_TIMEOUT in the server-src/chunker.c file
Running the script on the client might fix the issue
execute-where client
Even runing on the client it will take more than 300 seconds, would the
chunker
On 09/24/2014 07:03 AM, Olivier Nicole wrote:
Jean-Louis,
There is no parameter for that timeout. It is a constant in the program.
CONNECT_TIMEOUT in the server-src/chunker.c file
Running the script on the client might fix the issue
execute-where client
Even runing on the client
Hi,
For one specific DLE, I need to do a snapshot, through a pre-del-backup
script. But the script takes quite some time to complete (up to a
couple of hours). What timeout should I define to make Amanda wait for
the end of the script before it can chunk the result?
Example for the DLE amanda
There is no timeout in amrecover, it can wait for days.
Amrecover detect the error when the system return the error.
Jean-Louis
On 03/22/2013 05:25 AM, Nagai Megumu wrote:
Hello
I want you to teach about timeout of amrecover.
Execution a restore using the amrecover,time out network
Thankｓ.
It is such specification.
I am glad if it can adjust.
＿
Nagai
(2013/03/25 21:12), Jean-Louis Martineau wrote:
There is no timeout in amrecover, it can wait for days.
Amrecover detect the error when the system return the error.
Jean-Louis
On 03/22/2013 05:25 AM, Nagai Megumu wrote
Hello
I want you to teach about timeout of amrecover.
Execution a restore using the amrecover,time out network disconnected
later.But, it takes about 2 hours of time before it times out.
Work procedure
1.Run the extract in amrecover
2.While restoring files, the backup server and backup client
Hi there,
during amcheck I recieve the following notice.
WARNING: server.domain.de: selfcheck request failed: timeout waiting for ACK
Beside this entry all the different servers can be reached, that are listet in
the disklist. So I've read various diffrent error-reports, searched via google
On 03/15/2012 10:50 AM, Markus Lauterbach wrote:
Can anyone give me a short hint, where I should take a look to?
Do amandad is executed?
Look in the debug files and system log.
Jean-Louis
: Donnerstag, 15. März 2012 16:08
An: Markus Lauterbach
Cc: amanda-users@amanda.org
Betreff: Re: security_seterror(handle=0x7fcfd7d3f550, driver=0x7fcfd5aa8380
(BSD) error=timeout waiting for ACK)
On 03/15/2012 10:50 AM, Markus Lauterbach wrote:
Can anyone give me a short hint, where I should take
this is not my case as far as i can see, i have no iptables rules at
all and no firewall in the middle to block.
i tried to increase limitation of xinet.d and this does not change a
thing.
anyone else can think of something? anything? i will try all...
One problem I had early on, which you might be having:
When amanda starts a backup, the connection is held open for XX amount of time.
The client can reply back on that same connection . unless it takes longer
than that
to collect its data and get started. That could change as the data
Can you alaborate on what you did to fix this? What permission is missing? What
did you change? The client or the server?
--
Thanks,
Adi Spivak
Debra Baddorf badd...@fnal.gov wrote:
One problem I had early on, which you might be having:
When amanda starts a backup, the connection is held
My network guy made the change, but if was in some priv settings on the server
-- allowing the
client to initiate a new connection. Totally outside of amanda.
I think we were running free-BSD at the time. I can't find similar files right
now under Linux,
but it might have been in rules.ipf
Platform Solaris 10/Sparc. All client DLEs are on the
amanda server system.
The following amdump output is typical for this system.
I don't know why the timeout occurs, I do know that if I
run amdump on the single large DLE that is experiencing
the timeout problem that backups are successful
Brian,
Which auth are you using?
Post the debug files.
Jean-Louis
Brian Cuttler wrote:
Platform Solaris 10/Sparc. All client DLEs are on the
amanda server system.
The following amdump output is typical for this system.
I don't know why the timeout occurs, I do know that if I
run amdump
and 2.6.1-20090210 on
the client.
I already have fairly high timeout values for C/D/E timeout
are 500, 3600, 1500 respectively.
The client is a new install, in a DMZ, where the server is
within the campus network. Amchec reports all ok.
gtar is 1.23, gzip is 1.3.5, I am attempting to use zfs-snapshots
Brian Cuttler wrote:
1305727744.474545: amgtar: /usr/sfw/bin/gtar terminated with signal 11: see /tmp
/amanda/client/curie/amgtar.20110518100904000.debug
It is not a timeout issue, it is gtar that segfault
You can try to install a newer gtar or find why this one crash.
Jean-Louis
: amgtar: /usr/sfw/bin/gtar terminated with signal 11:
see /tmp
/amanda/client/curie/amgtar.20110518100904000.debug
It is not a timeout issue, it is gtar that segfault
You can try to install a newer gtar or find why this one crash.
Jean-Louis
---
Brian R Cuttler brian.cutt
, 2011 at 01:42:01PM -0400, Jean-Louis Martineau wrote:
Brian Cuttler wrote:
1305727744.474545: amgtar: /usr/sfw/bin/gtar terminated with signal 11:
see /tmp
/amanda/client/curie/amgtar.20110518100904000.debug
It is not a timeout issue, it is gtar that segfault
You can try to install a newer
I have setup a test configuration because of the issue I'm seeing on a
Solaris 10/x86 amanda 3.2.1 server/client. Auth is set to local.
The error from the amanda report is:
planner: ERROR xxx.math.utah.edu NAK: timeout on reply pipe
The test configuration has 11 DLEs. If I let the sendsize
: tempserv1: selfcheck request failed: timeout waiting for ACK
The planner debug file has lines like the following:
planner: time 0.099: connect_portrange: connect to 192.168.52.131.10080 failed:\
Connection refused
planner: stream_client: Could not bind to port in range 5 - 50040.
planner
when running amcheck:
WARNING: tempserv1: selfcheck request failed: timeout waiting for ACK
The planner debug file has lines like the following:
planner: time 0.099: connect_portrange: connect to 192.168.52.131.10080 failed:\
Connection refused
planner: stream_client: Could not bind to port
On Wed, Aug 18, 2010 at 8:37 AM, Brian Cuttler br...@wadsworth.org wrote:
I've seen this error appear several times on this particular system.
[request failed: timeout waiting for ACK](too)
A generic timeout waiting for ACK has lots of possible causes, as
outlined in the wiki. But I can't see
On Tue, Jun 1, 2010 at 9:39 AM, McGraw, Robert P rmcg...@purdue.edu wrote:
I am seeing several of the following dumper: [request failed: timeout
waiting for REP](too) errors when I run the amstatus command. Below is a
snippet of one of the errors.
Is the (too) really part of the error?
Can
I am running Amanda 2.6.1p2 on a Sun Solaris 10
I am seeing several of the following dumper: [request failed: timeout waiting
for REP](too) errors when I run the amstatus command. Below is a snippet of
one of the errors.
There were 57 DLE backups of the 57 4 gave the above error.
I ran
is
a timeout without *any* data, so I suspect that this is some kind of
ugly interaction between ZFS busily doing copy-on-write to implement
its snapshot while trying to feed data to the syscall-hungry gnutar.
I was thinking along those lines, just in a much less sophisticated
mannor. When
On Thu, May 6, 2010 at 1:44 PM, Brian Cuttler br...@wadsworth.org wrote:
Amanda is now failing differently.
tar exited with signal 11.
On Solaris, over a ZFS filesystem. We just saw this error a few days
ago on the list! Check the archives - there was a workaround.
--
Open Source Storage
What is the error? I suspect this:
1273071472.718696: dumper: security_seterror(handle=8074f08,
driver=fef09394 (BSD) error=timeout waiting for REP)
which likely means that you're exceeding the dtimeout for that DLE for
whatever reason. Try increasing that?
Dustin
--
Open Source Storage
).
Brian
On Wed, May 05, 2010 at 10:47:49AM -0500, Dustin J. Mitchell wrote:
What is the error? I suspect this:
1273071472.718696: dumper: security_seterror(handle=8074f08,
driver=fef09394 (BSD) error=timeout waiting for REP)
which likely means that you're exceeding the dtimeout
Brian,
I've found that on systems with alot of ZFS file systems I needed to
increase the {e,d,c}timeout values. Below are the values I have set and
I'm backing up some 150+ ZFS filesystems of varying sizes from a single
server, dumps are a mixture of suntar and zfs-sendrecv.
etimeout 1600
Darin,
On Wed, May 05, 2010 at 02:19:35PM -0400, Darin Perusich wrote:
Brian,
I've found that on systems with alot of ZFS file systems I needed to
increase the {e,d,c}timeout values. Below are the values I have set and
I'm backing up some 150+ ZFS filesystems of varying sizes from a single
On Wed, May 5, 2010 at 1:38 PM, Brian Cuttler br...@wadsworth.org wrote:
Also, the issues seem to be specific to certain DLE, in both
cases the busiest of the DLEs, not necessarily the largest
but the most active.
It's clearly timing-related, then. Keep in mind that hte dtimeout is
a timeout
.
It's clearly timing-related, then. Keep in mind that hte dtimeout is
a timeout without *any* data, so I suspect that this is some kind of
ugly interaction between ZFS busily doing copy-on-write to implement
its snapshot while trying to feed data to the syscall-hungry gnutar.
I was thinking
mycfgname, there's a 30 second pause, and then
this error:
AMRECOVER Version 2.6.1p2. Contacting server on localhost ...
[request failed: timeout waiting for ACK]
The .amandahosts file on the server has:
localhost root amindexd amidxtaped
localhost amandabackup amdump
localhost.localdomain
On Mon, Apr 19, 2010 at 8:50 AM, Craig Constantine cr...@blkbx.com wrote:
AMRECOVER Version 2.6.1p2. Contacting server on localhost ...
I'd recommend just using auth local if you're communicating within
the localhost. BSDTCP is just too annoying to get right.
Dustin
--
Open Source Storage
frequency. The server has 150+gig of work area
and this partition less than 35 gig.
The server sees a data timeout and quits, even when I run an amdump
of just this single partition, increasing dtimeout has not helped but
only increased time waiting for failure.
I don't see anything on the server
I am trying to solve an amcheck error.
Amanda Backup Client Hosts Check errors withselfcheck request failed:
timeout waiting for ACK.
I am simply trying to backup the local host (mother_inner) to a local tape
drive (HP-LTO4).
T
his is amanda-2.6.1_p2 on a 64bit gentoo machine, using xinetd
On Mon, Feb 1, 2010 at 10:32 AM, jo...@msli.com jo...@msli.com wrote:
I am trying to solve an amcheck error.
Amanda Backup Client Hosts Check errors withselfcheck request failed:
timeout waiting for ACK.
You're using BSD authentication, which is notoriously tricky to set up
and debug
, Dustin J. Mitchell wrote:
On Mon, Feb 1, 2010 at 10:32 AM, jo...@msli.com jo...@msli.com wrote:
I am trying to solve an amcheck error.
Amanda Backup Client Hosts Check errors withselfcheck request failed:
timeout waiting for ACK.
You're using BSD authentication, which is notoriously tricky
On Mon, Feb 1, 2010 at 11:37 AM, jo...@msli.com jo...@msli.com wrote:
Where do I read about why mother_inner isn't local?
You need to use the hostname 'localhost'. If this is a problem, you
should set up BSDTCP instead.
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
Perfect. Setting the one entery in /etc/amanda/Monthly_Mother/disklist
to localhost did it. Thank you!
After I follow man amanda-auth(7) carefully, I'll try bsdtcp.
BTW, a quick read through man amanda-auth(7), for more detailed
information, it sends me to
On Mon, Feb 1, 2010 at 12:13 PM, jo...@msli.com jo...@msli.com wrote:
I'm wondering if these circular document loops are helpful or needed.
Yes, we should take them out of the manpage. Thanks!
Dustin
--
Open Source Storage Engineer
http://www.zmanda.com
Should I file a bug some place? I'm not finding the bug page.
On Mon, 2010-02-01 at 12:22 -0600, Dustin J. Mitchell wrote:
On Mon, Feb 1, 2010 at 12:13 PM, jo...@msli.com jo...@msli.com wrote:
I'm wondering if these circular document loops are helpful or needed.
Yes, we should take them out
On Mon, Feb 1, 2010 at 12:36 PM, jo...@msli.com jo...@msli.com wrote:
Should I file a bug some place? I'm not finding the bug page.
We don't have a publicly-visible bug page at the moment. I'll take
care of it some time soon. If you'd like to make up a patch and post
it to the list, I can
On Mon, 2010-02-01 at 12:48 -0600, Dustin J. Mitchell wrote:
On Mon, Feb 1, 2010 at 12:36 PM, jo...@msli.com jo...@msli.com wrote:
Should I file a bug some place? I'm not finding the bug page.
We don't have a publicly-visible bug page at the moment. I'll take
care of it some time soon.
this week)
are checked sequentially.
We seem to be exceeding a timeout limit.
etimeout is for size estimates - so I don't think it applies.
We have switched to server estimate for zfs-dump.
Is there a per client amcheck estimate timeout, not based on
number of client DLEs ?
Amanda Backup Client Hosts
On 2009-05-13 00:24, James D. Freels wrote:
I got into debugging mode and discovered why this was happening.
Apparently this upgrade, or a recent change in AMANDA, now forces (or by
error) the data to be compressed with gzip before going from the client
to the server. Even if I specify compress
be that the upgrade to jaunty has nothing to do with this at
all, and it is just my own suspicion. I have never had timeout errors
before.
My workaround worked last night and I was able to get all the backups
working by running a large value for dtimeout.
I will work on your recommendations
On Tue, May 12, 2009 at 6:24 PM, James D. Freels f...@ornl.gov wrote:
I got into debugging mode and discovered why this was happening.
Apparently this upgrade, or a recent change in AMANDA, now forces (or by
error) the data to be compressed with gzip before going from the client
to the server.
On Tue, 12 May 2009 18:43:15 -0400
Dustin J. Mitchell dus...@zmanda.com wrote:
On Tue, May 12, 2009 at 6:24 PM, James D. Freels f...@ornl.gov wrote:
I got into debugging mode and discovered why this was happening.
Apparently this upgrade, or a recent change in AMANDA, now forces
(or by
COMPRESS_SUFFIX=.gz
COMPRESS_FAST_OPT=--fast
1241424302.908594: amandad:COMPRESS_BEST_OPT=--best
UNCOMPRESS_OPT=-dc
1241424302.908852: amandad: dgram_recv(dgram=ff4c, timeout=0,
fromaddr=ff343338)
1241424302.909008: amandad: (sockaddr_in *)ff343338 = { 0, 0, 0.0.0.0
CLIENT_LOGIN=amandabackup CHECK_USERID
1241424302.908588: amandad:HAVE_GZIP COMPRESS_SUFFIX=.gz
COMPRESS_FAST_OPT=--fast
1241424302.908594: amandad:COMPRESS_BEST_OPT=--best
UNCOMPRESS_OPT=-dc
1241424302.908852: amandad: dgram_recv(dgram=ff4c, timeout=0,
fromaddr
=amandabackup CHECK_USERID
1241424302.908588: amandad:HAVE_GZIP
COMPRESS_SUFFIX=.gz COMPRESS_FAST_OPT=--fast
1241424302.908594: amandad:COMPRESS_BEST_OPT=--best
UNCOMPRESS_OPT=-dc
1241424302.908852: amandad: dgram_recv(dgram=ff4c, timeout=0,
fromaddr=ff343338
]
host.domain.ee /usr lev 1 FAILED [cannot read header: got 0 instead
of 32768]
host.domain.ee /usr lev 1 FAILED [too many dumper retry: [request
failed: timeout waiting for ACK]]
sendbackup is dying early - possible your timeouts are set too low
in amanda.conf.
Is this new DLE big? Lots
/^\.//'
sendbackup: time 469.114: index tee cannot write [Broken pipe]
sendbackup: time 469.114: pid 11511 finish time Sat Feb 28 04:14:12 2009
It dies after 469 seconds. That doesn't seem to be a data timeout
(dtimeout defaults to 1800 seconds).
But often when you have a biggish DLE with lots
FAILED [too many dumper retry: [request
failed: timeout waiting for ACK]]
This shouldn't be a firewall problem, since the firewall on the
machine is set to unconditionally pass all traffic on loopback
interface and I couldn't find any relevant dropped packets in the
firewall log. Also amcheck
: got 0 instead
of 32768]
host.domain.ee /usr lev 1 FAILED [too many dumper retry: [request
failed: timeout waiting for ACK]]
This shouldn't be a firewall problem, since the firewall on the
machine is set to unconditionally pass all traffic on loopback
interface and I
since. Just thought I'd let the list know if anyone
else runs into this problem.
Jeremiah
Dustin J. Mitchell wrote:
It may be a simple timeout, since it only ever gets to 8.93% - have
you tried increasing dtimeout?
Dustin
0 FAILED [data timeout]
echo /usr lev 0 FAILED [too many dumper retry: [request failed:
timeout waiting for REP]]
echo /usr lev 0 FAILED [cannot read header: got 0 bytes instead of
32768]
FAILED DUMP DETAILS:
/-- echo /usr lev 0 FAILED [data timeout]me
sendbackup: start [echo:/usr
that is
failing is /usr. I'm having a hard time wrapping my brain around why I'm
never able to get it to dump.
It may be a simple timeout, since it only ever gets to 8.93% - have
you tried increasing dtimeout?
Dustin
--
Storage Software Engineer
http://www.zmanda.com
1 - 100 of 580 matches
Mail list logo
