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 are
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 "etim
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 anno
out.
> >
> > 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]
> > m
> 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
gging. 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/amanda/vtapes/daily/slot9 lev 0 FAILED [dumper returned
FAILED]
monza /data/backup/amanda/vtapes/daily/slot9 lev 0 FAILED [da
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 hou
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
tc had been
> making it happy for years?
>
> So now amcheck is happy, and a real backup is running.
>
> Damn I'd like to find 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
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 d
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 m
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. Pleas
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
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 w
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
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,
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 i
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 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 d
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
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 3
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:
gene@coyote:/usr/local/etc/amanda/Dai
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 & smal
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 reboo
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
see
ore the
16th?
If it was nowhere near 6 hours, 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
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 working
&
6th?
If it was nowhere near 6 hours, 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
using.
-Original Message-
From: 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
ectly 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
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/21/2015 03:52 PM, Chris Hoogendyk wrote:
First note that regardless of the timing for any
e:
On Wed, Jan 21, 2015 at 14:40:31 -0500, Chris Hoogendyk wrote:
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
Quick "stab in the
e:
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 t
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 Amand
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 t
t; 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 the default of 3 down to 2. This reduces my
>> freeze time from
>> 9 minutes to 6. I’m not sure lowering “c
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
( 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 the
>>> 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 c
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 it will
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 sec
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
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
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:2
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
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
martin...@zmanda.com]
Gesendet: 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 sho
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
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-report
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...
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
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 wrote:
One problem I had early on, which you might be having:
When amanda starts a backup, the connection is held open for XX amount
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 inc
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 amdu
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 succe
, 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 tha
44.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.
>
&g
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
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
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
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 in
: 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
On Wed, Aug 18, 2010 at 8:37 AM, Brian Cuttler 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
Dustin,
I've seen this error appear several times on this particular system.
[request failed: timeout waiting for ACK](too)
The result is that we have processes that don't self-terminate
after amanda completes. This causes the particular DLE to fail
on subsequent days.
Not sure what
On Tue, Jun 1, 2010 at 9:39 AM, McGraw, Robert P 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
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 erro
On Thu, May 6, 2010 at 1:44 PM, Brian Cuttler 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 Engineer
http://ww
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 without *any* data, so I suspect that
ost active.
>
> 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 sys
On Wed, May 5, 2010 at 1:38 PM, Brian Cuttler 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 timeou
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 filesystem
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.
eti
only the global-zone).
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 me
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 St
On Mon, Apr 19, 2010 at 8:50 AM, Craig Constantine 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 Engineer
http:
"amrecover 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 amdu
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 s
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 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 l
On Mon, Feb 1, 2010 at 12:36 PM, 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 take care of it e
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 wrote:
> > I'm wondering if these circular document loops are helpful or needed.
>
> Yes, we should take them out of the ma
On Mon, Feb 1, 2010 at 12:13 PM, 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
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
http://wiki.zmanda.com/index.php/Serv
On Mon, Feb 1, 2010 at 11:37 AM, 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
ocal?
On Mon, 2010-02-01 at 10:58 -0600, Dustin J. Mitchell wrote:
> On Mon, Feb 1, 2010 at 10:32 AM, jo...@msli.com wrote:
> > I am trying to solve an amcheck error.
> > "Amanda Backup Client Hosts Check" errors with"selfcheck request failed:
> > timeout
On Mon, Feb 1, 2010 at 10:32 AM, jo...@msli.com wrote:
> I am trying to solve an amcheck error.
> "Amanda Backup Client Hosts Check" errors with"selfcheck request failed:
> timeout waiting for ACK".
You're using BSD authentication, which is notoriously tricky t
I am trying to solve an amcheck error.
"Amanda Backup Client Hosts Check" errors with"selfcheck 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 m
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 ?
Amand
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 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
On Tue, 12 May 2009 18:43:15 -0400
"Dustin J. Mitchell" wrote:
> On Tue, May 12, 2009 at 6:24 PM, 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 com
On Tue, May 12, 2009 at 6:24 PM, 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
;
>> 1241424302.908537: amandad:GNUTAR="/usr/sfw/bin/gtar"
>> COMPRESS_PATH="/usr/bin/gzip"
>> 1241424302.908543: amandad:UNCOMPRESS_PATH="/usr/bin/
>> gzip" LPRCMD="/usr/bin/lp"
>> 1241424302.908550: amandad:
CURITY
1241424302.908582: amandad: USE_AMANDAHOSTS
CLIENT_LOGIN="amandabackup" CHECK_USERID
1241424302.908588: amandad:HAVE_GZIP COMPRESS_SUFFIX=".gz"
COMPRESS_FAST_OPT="--fast"
1241424302.908594: amandad:COMPRESS_BEST_OPT
"
1241424302.908569: amandad:HAVE_MMAP NEED_STRSTR
HAVE_SYSVSHM AMFLOCK_POSIX AMFLOCK_LOCKF
1241424302.908575: amandad:AMFLOCK_LNLOCK SETPGRP_VOID
AMANDA_DEBUG_DAYS=4 BSD_SECURITY
1241424302.908582: amandad: USE_AMANDAHOSTS
CLIENT_LOGIN="amand
John Hein wrote:
It's also possible you're hitting a udp datagram size limit.
Looks like this was indeed the problem. After increasing
net.inetudp.maxdgram to 65535 I've now had two successful backups.
Thanks for your help.
--
Toomas
;:
.
.
> sendbackup: time 0.014: started index creator: "/usr/local/bin/gtar -tf -
> 2>/dev/null | sed -e 's/^\.//'"
> sendbackup: time 469.114: index tee cannot write [Broken pipe]
> sendbackup: time 469.114: pid 11511 finish time Sat Feb 28 04:14:12 2
main.ee /usr lev 1 FAILED [cannot read header: got 0 instead
> > of 32768]
> > 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: timeou
1 - 100 of 616 matches
Mail list logo
