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
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
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 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
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
Thanks very much for the help, this is pretty urgent now.
I tried doing that, here's the new problem:
This is the inetadm output:
bash-3.00# inetadm -l svc:/network/amanda/tcp:default
SCOPENAME=VALUE
name="amanda"
endpoint_type="stream"
proto="tcp"
isrpc=F
Add '-auth=bsdtcp" in argument to amandad.
Jean-Louis
Abilio Carvalho wrote:
I'm getting this message when trying to run amcheck. I've run
amservice as is specified in the wiki page about this error, and I'm
getting the same error, so it's a client issue. Can someone help me
debug this?
I'm getting this message when trying to run amcheck. I've run
amservice as is specified in the wiki page about this error, and I'm
getting the same error, so it's a client issue. Can someone help me
debug this?
I've checked the client logs, and the only thing I can find that's
relevant is
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
Toomas Aas wrote at 10:13 +0200 on Mar 1, 2009:
> Sunday 01 March 2009 04:59:54 kirjutasid sa:
> > Is this new DLE big? Lots of files?
>
> The new DLE is not that big. Its 'raw capacity' is 21 GB, ca 25000 files,
> but
> most of it are MySQL and PostgreSQL database files which are exclud
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
.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]"]
>
> This shouldn't be a firewall problem, since the firewall on the
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 couldn't find any relevant dropped packets in the
f
f the critical client, it's worked.
If i add some more partition, it does not.
When i launch an amdump, i got on the client side
amandad.20080619210546000.debug this error.
amandad: time 268.633: waiting for ack: timeout, retrying
amandad: time 278.631: dgram_recv: timeout after 10 seconds
ama
s multiple virtual ethernet
interfaces. In other words, it has one physical wire, but there
are multiple virtual interfaces assigned to that wire.
The problem is that amcheck to this multi-homed client fails with:
WARNING: AA.BB.CC.edu: selfcheck request failed: timeout waiting for ACK
Interesti
failed: timeout waiting for ACK
Interestingly, this worked in Amanda-2.4.5, but now fails in
Amanda-2.6.0.
BTW - The primary reason I'm upgrading is because under Amanda-2.4.5,
killpgrp is periodically killing extra processes and hosing one of my
machines. Unfortunately, when the machine goes dow
It seems to have resolved overnight. Strangely, I looked at my command
history, and I definitely turned the firewall off two days ago, before
the last set of failures. I'm just going to assume I screwed up and the
firewall was still on for the last set of failures even though that
doesn't s
E 240
>>>>>
amandad: time 907.895: timeout
amandad: time 907.895: sending REP pkt:
<<<<<
OPTIONS features=feff9ffe07;
/opt/zimbra/backup 0 SIZE 88848410
/opt/zimbra/backup 1 SIZE 381010
/opt/zimbra/backup 2 SIZE 358270
/etc 0 SIZE 93230
/etc 1 SIZE 240
&g
Is this a firewall problem, perhaps? Those packets translate to UDP
packets in bsd auth, and if there's some connection tracking going on,
it would probably reject a reply packet after 800+ seconds.
If that doesn't prove to be the case, take a look at a tcpdump of the
connection, to see whether t
Thanks, that did the trick (added bind address)...
>Force the listen address in the relevant xinetd.d file. This will do the
> trick.
--
Luc Lalonde, analyste
-
Département de génie informatique:
Éole polytechnique de Montréal
er, if I do it with the secondary addr (192.168.1.25), I
> get this message:
>
> WARNING: secon-ip: selfcheck request failed: timeout waiting for ACK
>
> Where, secon-ip is 192.168.1.25. I did a "tcpdump -A -v -v udp port
> 10080" and it confirms that the Amanda s
0:6546/64 scope link
valid_lft forever preferred_lft forever
When I do an "amcheck" on the primary addr (192.168.1.23) , all is
fine... However, if I do it with the secondary addr (192.168.1.25), I
get this message:
WARNING: secon-ip: selfcheck request failed: timeout waiting fo
On Sun, 2007-06-24 at 19:37 -0700, fedora wrote:
> I'm using Amanda version 2.5.1p3 for server and clients. The OS I used is
> RHEL4. The problem is the result was not occur for all clients. Before this
> the Amanda server can do backup and the result only showed STRANGE not
> FAILED OR MISSING. Th
ent10 /var/lib/mysql RESULTS MISSING
planner: ERROR Request to client7 failed: timeout waiting for ACK
planner: ERROR Request to client8 failed: timeout waiting for ACK
planner: ERROR Request to client1 failed: timeout waiting for ACK
planner: ERROR Request to client9 failed: timeout wa
Chris Hoogendyk wrote:
> fedora wrote:
>
>> Hi guys,
>>
>> If my Amanda shows error like timeout waiting for ACK, which debug file its
>> in? I can't find that error in any debug files. One more thing, assume that
>> all settings are right, is it
fedora wrote:
> Hi guys,
>
> If my Amanda shows error like timeout waiting for ACK, which debug file its
> in? I can't find that error in any debug files. One more thing, assume that
> all settings are right, is it possible that the error caused by network
> which is sl
On Fri, Jun 22, 2007 at 10:02:02PM -0700, fedora wrote:
>
> Hi guys,
>
> If my Amanda shows error like timeout waiting for ACK, which debug file its
> in? I can't find that error in any debug files. One more thing, assume that
> all settings are right, is it possible t
Hi guys,
If my Amanda shows error like timeout waiting for ACK, which debug file its
in? I can't find that error in any debug files. One more thing, assume that
all settings are right, is it possible that the error caused by network
which is slow or up and down?? Pls guide.
--
View
Hi,
Leonid Shulov schrieb:
netstat -na |grep 10080 - do nothing.
Then the service is not running. Is it running, when you restart (x)inetd? If
not, then check the system logfile if there are any compliants about that
service entry. If you can't fix it, then please post the error of the
(x)ine
> netstat -na |grep 10080 - do nothing.
Hummm, I don't use debian, but if you get nothing it would tend to
mean that amandad is not running on that machine, so when the server
call, nobody answers.
Olivier
, time 2000ms
rtt min/avg/max/mdev = 0.014/0.019/0.023/0.005 ms
I don't reboot server because my staff is all time work on it.
On Mon, 2007-06-18 at 15:04 +0700, Olivier Nicole wrote:
> > After amcheck I see this message:
> > planner: ERROR Request to asnserv1 failed: timeou
> After amcheck I see this message:
> planner: ERROR Request to asnserv1 failed: timeout waiting for ACK
What system is Amanda server runnig on? What did you change few days
ago?
Did you reboot the machine and the problem is still there?
What is the result of the following c
Hi NG,
I use amanda 5 years and now I have mystical problem.
My amanda server do backup from all my servers, PC's and notebooks
except self backup.
This happened few days ago.
After amcheck I see this message:
planner: ERROR Request to asnserv1 failed: timeout waiting for ACK
In /tmp/amand
On Friday 11 May 2007, Paul Bijnens wrote:
>On 2007-05-11 14:36, Donofrio, Lewis wrote:
>> Yes that sounds about right, I thought rait required like devices to
>> stripe to?
>
>It's not the first time people are pleasantly surprised by the
>power of the amanda backup programs :-)
>
>
>From the wiki
On 2007-05-11 14:36, Donofrio, Lewis wrote:
> Yes that sounds about right, I thought rait required like devices to
> stripe to?
It's not the first time people are pleasantly surprised by the
power of the amanda backup programs :-)
>From the wiki page, I mentioned:
RAIT with only two drives, cre
Amanda List
Sent: Fri May 11 08:29:29 2007
Subject: Re: Since 2.5.2: Timeout waiting for ACK
On 2007-05-11 14:11, Donofrio, Lewis wrote:
> [...] Two Amanda runs
> moving data from clients to holding disk then from holding disk to
> vtapes. Another job to migrate the data from the vtapes
On 2007-05-11 14:11, Donofrio, Lewis wrote:
> [...] Two Amanda runs
> moving data from clients to holding disk then from holding disk to
> vtapes. Another job to migrate the data from the vtapes to the holding
> disk to physical tapes (old ati2 w/tls4440 jukebox).
I'm not completely sure I under
; WARNING: wilf: selfcheck request failed: timeout waiting for ACK
> Client check: 1 host checked in 30.002 seconds, 1 problem found
>
> (brought to you by Amanda 2.5.1p1)
>
> I'm using the above version of AMANDA on a Debian system (unstable
> release).
>
> This was unins
Gene Heskett wrote:
On Tuesday 19 September 2006 08:10, Jean-Louis Martineau wrote:
Hi,
I found the problem that lead to the "timeout waiting for ACK" error.
If you have this problem, try the latest 2.5.1 snapshot from
http://www.iro.umontreal.ca/~martinea/amanda
Jean-Louis
On Tuesday 19 September 2006 11:03, Jean-Louis Martineau wrote:
>Gene Heskett wrote:
>> On Tuesday 19 September 2006 08:10, Jean-Louis Martineau wrote:
>>> Hi,
>>>
>>> I found the problem that lead to the "timeout waiting for ACK" error.
>>
On Tuesday 19 September 2006 10:20, Tobias Weingartner wrote:
>On Tuesday, September 19, Jean-Louis Martineau wrote:
>> I found the problem that lead to the "timeout waiting for ACK" error.
>>
>> If you have this problem, try the latest 2.5.1 snapshot from
>>
On Tuesday 19 September 2006 08:10, Jean-Louis Martineau wrote:
>Hi,
>
>I found the problem that lead to the "timeout waiting for ACK" error.
>
>If you have this problem, try the latest 2.5.1 snapshot from
>http://www.iro.umontreal.ca/~martinea/amanda
>
>Jean-Loui
1 driver:
(aborted:[request failed: timeout waiting for ACK])(too many dumper
retry)
pille.hq.imos.net:/usr 0 3505m
finished (1:53:08)
pille.hq.imos.net:/var 0 driver:
(aborted:[request failed: timeout waiting for ACK])(too m
q.imos.net:/ 0 252m
finished (2:08:23)
pille.hq.imos.net:/opt 1 driver:
(aborted:[request failed: timeout waiting for ACK])(too many dumper retry)
pille.hq.imos.net:/usr 0 3505m
finished (1:53:08)
pille.h
versions:
server: 2.5.0b2
client: 2.4.5p1
"amstatus daily" tells the following:
pille.hq.imos.net:/ 0 252m
finished (2:08:23)
pille.hq.imos.net:/opt 1 driver:
(aborted:[request failed: timeout waiting for ACK])(too m
Am 02.03.2006 um 18:40 schrieb Kevin Till:
Stefan Herrmann wrote:
Am 01.03.2006 um 23:21 schrieb Kevin Till:
is firewall running on the client? If so, it needs to open some TCP
ports for DATA/MESG/INDEX communication.
no packet filter on server and client, they are both running in an
internal
Stefan Herrmann wrote:
Am 01.03.2006 um 23:21 schrieb Kevin Till:
that's the email i got from the last amdump:
These dumps were to tape hourly025.
The next 2 tapes Amanda expects to use are: a new tape, a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
pille.hq.imos.net /usr lev 1 FAILED [can
Am 01.03.2006 um 23:21 schrieb Kevin Till:
that's the email i got from the last amdump:
These dumps were to tape hourly025.
The next 2 tapes Amanda expects to use are: a new tape, a new tape.
FAILURE AND STRANGE DUMP SUMMARY:
pille.hq.imos.net /usr lev 1 FAILED [cannot read header: got 0
i
Stefan Herrmann wrote:
Am 23.02.2006 um 16:15 schrieb Paul Bijnens:
On 2006-02-23 15:54, Stefan Herrmann wrote:
i think there was no useful information in the leftout part, but look
for yourself:
Yes indeed. No REQ packet at all.
Are you sure this debug file is the result from a amdump re
Am 23.02.2006 um 16:15 schrieb Paul Bijnens:
On 2006-02-23 15:54, Stefan Herrmann wrote:
i think there was no useful information in the leftout part, but look
for yourself:
Yes indeed. No REQ packet at all.
Are you sure this debug file is the result from a amdump request,
and not one of those
Am 23.02.2006 um 18:06 schrieb Jon LaBadie:
On Thu, Feb 23, 2006 at 02:24:59PM +0100, Stefan Herrmann wrote:
Does amcheck pass all tests?
yes:
[EMAIL PROTECTED]:~$ amcheck hourly
Amanda Tape Server Host Check
A config named "hourly". Do you actually run amdump each hour?
If so, might there
On Thu, Feb 23, 2006 at 02:24:59PM +0100, Stefan Herrmann wrote:
>
>
> >Does amcheck pass all tests?
>
> yes:
>
> [EMAIL PROTECTED]:~$ amcheck hourly
> Amanda Tape Server Host Check
A config named "hourly". Do you actually run amdump each hour?
If so, might there be some extraneous, old, stuc
On 2006-02-23 15:54, Stefan Herrmann wrote:
i think there was no useful information in the leftout part, but look
for yourself:
Yes indeed. No REQ packet at all.
Are you sure this debug file is the result from a amdump request,
and not one of those that were generated by all different commands
Am 23.02.2006 um 14:43 schrieb Paul Bijnens:
On 2006-02-23 14:24, Stefan Herrmann wrote:
Am 23.02.2006 um 11:17 schrieb Paul Bijnens:
I would take a look in the debug files on the client, usually in
the dir /tmp/amanda/. There you can see files
"amandad.datetime.debug"
which contain the pack
On 2006-02-23 14:24, Stefan Herrmann wrote:
Am 23.02.2006 um 11:17 schrieb Paul Bijnens:
I would take a look in the debug files on the client, usually in
the dir /tmp/amanda/. There you can see files "amandad.datetime.debug"
which contain the packet received, and the replies. If there
are no
:[request failed: timeout
waiting for ACK])(too many dumper retry)
pille.hq.imos.net:/opt 1 driver: (aborted:[request failed: timeout
waiting for ACK])(too many dumper retry)
pille.hq.imos.net:/usr 1 driver: (aborted:[request failed: timeout
waiting for ACK])(too many dumper retry)
pille.hq.imos.net
On 2006-02-23 10:45, Stefan Herrmann wrote:
this is one of my amstatus reports:
[EMAIL PROTECTED]:~/hourly$ amstatus hourly
Using /usr/local/etc/amanda/hourly/amdump.1 from Thu Feb 23 10:20:59 CET
2006
pille.hq.imos.net:/0 driver: (aborted:[request failed: timeout
waiting for ACK])(too
this is one of my amstatus reports:
[EMAIL PROTECTED]:~/hourly$ amstatus hourly
Using /usr/local/etc/amanda/hourly/amdump.1 from Thu Feb 23 10:20:59
CET 2006
pille.hq.imos.net:/0 driver: (aborted:[request failed: timeout
waiting for ACK])(too many dumper retry)
pille.hq.imos.net:/opt 1
ntioned an error in
the amanda.conf and aborted the dump
manually. stopped all amanda processes on the client manually and
corrected the error. since then i get lots of
"(aborted:[request failed: timeout waiting for ACK])(too many dumper
retry)" when doing backups:
Anytime I hear "ma
the amanda.conf and aborted the dump
> manually. stopped all amanda processes on the client manually and
> corrected the error. since then i get lots of
> "(aborted:[request failed: timeout waiting for ACK])(too many dumper
> retry)" when doing backups:
>
Anytime I hea
; i did some test backups that worked ok. then i mentioned an error in
> the amanda.conf and aborted the dump
> manually. stopped all amanda processes on the client manually and
> corrected the error. since then i get lots of
> "(aborted:[request failed: timeout waiting for ACK]
nually and
corrected the error. since then i get lots of
"(aborted:[request failed: timeout waiting for ACK])(too many dumper
retry)" when doing backups:
[EMAIL PROTECTED]:~$ amstatus hourly
Using /usr/local/etc/amanda/hourly/amdump.1 from Tue Feb 21 09:22:36
CET 2006
pille.hq.im
In a message dated: Tue, 18 Dec 2001 13:38:58 EST
Yura Pismerov said:
>http://amanda.sourceforge.net/cgi-bin/fom?_highlightWords=firewall&file=16
Thanks, except it's not a firewall problem, nor was amcheck reporting
errors.
As I pointed out in a subsequent post/followup, the problem appears
Paul Lussier wrote:
>
> I'm having problems backing up one particular host on my network.
> amandad.debug reports:
>
> amandad: waiting for ack: timeout, retrying
> amandad: waiting for ack: timeout, retrying
> amandad: waiting
Paul Lussier wrote:
>
> I'm having problems backing up one particular host on my network.
> amandad.debug reports:
>
> amandad: waiting for ack: timeout, retrying
> amandad: waiting for ack: timeout, retrying
> amandad: waiting
In a message dated: Tue, 18 Dec 2001 11:17:17 EST
Paul Lussier said:
>I'm having problems backing up one particular host on my network.
>amandad.debug reports:
>
> amandad: waiting for ack: timeout, retrying
> amandad: waiting for ack: timeout, retrying
>
I'm having problems backing up one particular host on my network.
amandad.debug reports:
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: timeout, retrying
amandad: waiting for ack: ti
<-- Snip -->>
What RPMs did you update? Did you setup some firewalling by default?
<-- Snip -->>
Boy I wish I could answer that one. RedHat has made it so simple to keep
your system updated using the RedHat Network that I no longer have to
manually update the system. Hence I'm kind of oblivious
ad: waiting for ack: Connection refused, retrying
> followed by one line of
> amandad: waiting for ack: Connection refused, giving up!
> Any hints as to what went wrong?
What RPMs did you update? Did you setup some firewalling by default?
Thanks for the reply! All help is greatly appreciated!
I have checked both the server and client machines for the services. They
are auto starting. I have even restarted xinetd.
As far as the RPM updates, Amanda was not one of them so the amanda.rpmnew
file did not exist.
I don't think it is tc
ent. I get 4 lines of
> amandad: waiting for ack: Connection refused, retrying
> followed by one line of
> amandad: waiting for ack: Connection refused, giving up!
> Any hints as to what went wrong?
>
> James
>
try running 'ntsysv' and double checking that '
I am having difficulties in running amanda. I am unable to get a backup (but
once was) and I think it was after updating some RPM on my system. It takes
30 minutes to fail and the only info I can find in in the amandad.debug file
on the client. I get 4 lines of
amandad: waiting for ack
90 matches
Mail list logo
