selfcheck request failed: timeout waiting for ACK
I have been trying to get this issue resloved all week, and finally
decided to ask others. I did searching on the web and tried what I
have read, but no success.
I am using Amanda 2.5.1. Yes, I know it is old, but it works. Well, it
had been working until I moved everything to a different machine. The
new machine is running Fedora 14. Amanda is built from source. I used
the configuration files (amanda.conf, disklist,...) from my old set
up. I am backing up the data to disk. My linux backups work without
issue. My Windows boxes all fail with this error 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 range 5 - 50040.
planner: stream_client: Could not bind to any port: Connection refused
security_seterror(handle=0x81d2ea0, driver=0xd27140 (BSDTCP) error=Connection r\
efused)
I built the programs with configure options that included the following:
--with-udpportrange=850,854 --with-tcpportrange=5,50040
--with-smbclient=/usr/bin/smbclient
I did copy over the .amandahosts file from the old machine to the
knew. I also made sure that xinetd amanda file was the same. Well,
here is the current one:
service amanda
{
disable = no
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = root
server = /usr/lib/amanda/amandad
server_args = -auth=bsd amdump
}
I dont think the one from the old machine had the -auth=bsd amdump lines.
The ip address, 192.168.52.131, is the localhost. Netstat show the following:
tcp0 0 :::10082:::*LIST
EN
udp0 0 :::10080:::*
So the ports are open. I have turned off iptables. Both 127.0.0.1 and
192.168.52.131 are in the hosts.allow file.
I do have other older fedora installs with the amanda 2.5.1 that are
able to talk to otehr windows boxes without issue.
Does anyone have any suggestions on what to try next. I think the
problem is simple, but I must have my blinders on and can't see the
solution.
Thanks
Re: selfcheck request failed: timeout waiting for ACK
jf...@bnext.stucen.gatech.edu wrote:
I have been trying to get this issue resloved all week, and finally
decided to ask others. I did searching on the web and tried what I
have read, but no success.
I am using Amanda 2.5.1. Yes, I know it is old, but it works. Well, it
had been working until I moved everything to a different machine. The
new machine is running Fedora 14. Amanda is built from source. I used
the configuration files (amanda.conf, disklist,...) from my old set
up. I am backing up the data to disk. My linux backups work without
issue. My Windows boxes all fail with this error 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 range 5 - 50040.
planner: stream_client: Could not bind to any port: Connection refused
security_seterror(handle=0x81d2ea0, driver=0xd27140 (BSDTCP) error=Connection r\
efused)
You try to use BSDTCP auth
I built the programs with configure options that included the following:
--with-udpportrange=850,854 --with-tcpportrange=5,50040
--with-smbclient=/usr/bin/smbclient
I did copy over the .amandahosts file from the old machine to the
knew. I also made sure that xinetd amanda file was the same. Well,
here is the current one:
service amanda
{
disable = no
socket_type = dgram
protocol= udp
wait= yes
user= operator
group = root
server = /usr/lib/amanda/amandad
server_args = -auth=bsd amdump
}
but xinetd is configured for BSD auth
I dont think the one from the old machine had the -auth=bsd amdump lines.
The ip address, 192.168.52.131, is the localhost. Netstat show the following:
tcp0 0 :::10082:::*LIST
EN
udp0 0 :::10080:::*
So the ports are open. I have turned off iptables. Both 127.0.0.1 and
192.168.52.131 are in the hosts.allow file.
I do have other older fedora installs with the amanda 2.5.1 that are
able to talk to otehr windows boxes without issue.
Does anyone have any suggestions on what to try next. I think the
problem is simple, but I must have my blinders on and can't see the
solution.
Thanks
Which auth do you want to use? configure both the disklist and xinetd to
use the same auth.
An xinetd file for bsdtcp:
service amanda
{
disable = no
socket_type = stream
protocol= tcp
wait= no
user= operator
group = root
server = /usr/lib/amanda/amandad
server_args = -auth=bsdtcp amdump
}
Jean-Louis
new instlal, selfcheck request failed: timeout waiting for ACK
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.
Full output of amcheck:
su amanda -c /usr/sbin/amcheck Monthly_Mother
Amanda Tape Server Host Check
-
Holding disk /backup/dumps: 625549312 KB disk space available, using
625446912 KB
read label `Monthly_Mother-01', date `X'.
NOTE: skipping tape-writable test
Tape Monthly_Mother-01 label ok
NOTE: conf info dir /var/log/amanda/Monthly_Mother/curinfo does not
exist
NOTE: it will be created on the next run.
NOTE: index dir /var/log/amanda/Monthly_Mother/index does not exist
NOTE: it will be created on the next run.
Server check took 0.066 seconds
Amanda Backup Client Hosts Check
WARNING: mother_inner:: selfcheck request failed: timeout waiting for
ACK
Client check: 1 host checked in 30.033 seconds. 1 problem found.
(brought to you by Amanda 2.6.1p2)
I know it is listening based on netstat and lsof.
netstat -a | grep amanda
tcp0 0 mother_inner:amandaidx *:*
LISTEN
udp0 0 mother_inner:amanda *:*
lsof -c xinetd
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
xinetd 14641 root cwdDIR8,2 8962 /
xinetd 14641 root rtdDIR8,2 8962 /
xinetd 14641 root txtREG8,2 149424 4211662
/usr/sbin/xinetd
xinetd 14641 root memREG8,243384 10141648
/lib64/libnss_nis-2.10.1.so
xinetd 14641 root memREG8,231432 10141670
/lib64/libnss_compat-2.10.1.so
xinetd 14641 root memREG8,247432 10141649
/lib64/libnss_files-2.10.1.so
xinetd 14641 root memREG8,2 1399984 10141335
/lib64/libc-2.10.1.so
xinetd 14641 root memREG8,239016 10141677
/lib64/libcrypt-2.10.1.so
xinetd 14641 root memREG8,2 534648 10141639
/lib64/libm-2.10.1.so
xinetd 14641 root memREG8,20 10141657
/lib64/libnsl-2.10.1.so
xinetd 14641 root memREG8,2 123168 10141666
/lib64/ld-2.10.1.so
xinetd 14641 root memREG8,233832 274214
/lib64/libwrap.so.0.7.6
xinetd 14641 root0r CHR1,3 0t0 2953
/dev/null
xinetd 14641 root1r CHR1,3 0t0 2953
/dev/null
xinetd 14641 root2r CHR1,3 0t0 2953
/dev/null
xinetd 14641 root3r FIFO0,6 0t0 3060137 pipe
xinetd 14641 root4w FIFO0,6 0t0 3060137 pipe
xinetd 14641 root5u IPv43060165 0t0 UDP
mother_inner:amanda
xinetd 14641 root6u IPv43060166 0t0 TCP
mother_inner:amandaidx (LISTEN)
xinetd 14641 root7u unix 0x8801440d3740 0t0 3060144
socket
xinetd 14641 root8u IPv43060167 0t0 TCP
mother_inner:amidxtape (LISTEN)
I verified my name name resolution
grep mother_inner /etc/hosts
192.168.0.60 mother_inner
Getting into the backup scripts:
/etc/amanda/Monthly_Mother/disklist
mother_inner / root-tar
/etc/amanda/Monthly_Mother/amanda.conf
org Monthly_Mother
mailto root
dumpuser amanda
inparallel 4
dumporder sssS
taperalgo first
displayunit k
netusage 8000 Kbps
dumpcycle 4 weeks
runspercycle 1
tapecycle 2 tapes
bumpsize 20 Mb
bumppercent 20
bumpdays 1
bumpmult 4
etimeout 300
dtimeout 1800
ctimeout 30
device_output_buffer_size 1280k
usetimestamps yes
flush-threshold-dumped 0
flush-threshold-scheduled 0
taperflush 0
autoflush no
runtapes 1
tapedev tape:/dev/nst0
maxdumpsize -1
tapetype HP-LTO4
labelstr ^Monthly_Mother-[0-9][0-9]*$
amrecover_do_fsf yes
amrecover_check_label yes
amrecover_changer changer
holdingdisk hd1 {
comment main holding disk
directory /backup/dumps
use -100 Mb
chunksize 1Gb
}
infofile /var/log/amanda/Monthly_Mother/curinfo
logdir /var/log/amanda/Monthly_Mother
indexdir /var/log/amanda/Monthly_Mother
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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. It looks like you are trying to back up the Amanda server itself, so I would suggest using LOCAL auth, which does not require any (x)inetd configuration at all. If you are connecting to a remote machine, I would suggest that you use BSDTCP instead, or (if you can set it up) SSH. See the amanda-authentication(7) manpage for details. Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: new instlal, selfcheck request failed: timeout waiting for ACK
This is both the server and client, and eventually I hope to add more
clients.
the man amanda-auth(7) , didn't tell me how to configure 'local'.
Once I change amanda.conf section
define dumptype root-tar {}
to include: auth local
Now:
su amanda -c /usr/sbin/amcheck Monthly_Mother
reports:
Amanda Backup Client Hosts Check
WARNING: mother_inner: selfcheck request failed: mother_inner: is not
local
Client check: 1 host checked in 10.012 seconds. 1 problem found.
Where do I read about why mother_inner isn't local?
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 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.
It looks like you are trying to back up the Amanda server itself, so I
would suggest using LOCAL auth, which does not require any (x)inetd
configuration at all.
If you are connecting to a remote machine, I would suggest that you
use BSDTCP instead, or (if you can set it up) SSH.
See the amanda-authentication(7) manpage for details.
Dustin
CONFIDENTIALITY NOTICE: This electronic mail message and any attachment hereto
may contain confidential information of Meyer Sound Laboratories, Incorporated
and is intended for the personal and confidential use of the designated
recipient(s) only. If you are not the intended recipient (or responsible for
delivering the message to the intended recipient), you have received this
message in error and any review, distribution, or copying of this message or
any attachment hereto is prohibited. If you have received this message in
error, please promptly notify the sender and permanently delete it from your
computer.
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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/Server/Client_authentication which sends me to man amanda-auth(7). A document loop? Additionally, for details on bsdtcp, man amanda-auth(7) page sends me to http://wiki.zmanda.com/index.php/Configuring_bsd/bsdudp/bsdtcp_authentication which says: For the authoritative documentation on configuring authentication in Amanda, see amanda-auth(7) Another document loop? I'm wondering if these circular document loops are helpful or needed. On Mon, 2010-02-01 at 11:57 -0600, Dustin J. Mitchell wrote: 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 CONFIDENTIALITY NOTICE: This electronic mail message and any attachment hereto may contain confidential information of Meyer Sound Laboratories, Incorporated and is intended for the personal and confidential use of the designated recipient(s) only. If you are not the intended recipient (or responsible for delivering the message to the intended recipient), you have received this message in error and any review, distribution, or copying of this message or any attachment hereto is prohibited. If you have received this message in error, please promptly notify the sender and permanently delete it from your computer.
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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 of the manpage. Thanks! Dustin CONFIDENTIALITY NOTICE: This electronic mail message and any attachment hereto may contain confidential information of Meyer Sound Laboratories, Incorporated and is intended for the personal and confidential use of the designated recipient(s) only. If you are not the intended recipient (or responsible for delivering the message to the intended recipient), you have received this message in error and any review, distribution, or copying of this message or any attachment hereto is prohibited. If you have received this message in error, please promptly notify the sender and permanently delete it from your computer.
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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 take care of it even sooner :) Dustin -- Open Source Storage Engineer http://www.zmanda.com
Re: new instlal, selfcheck request failed: timeout waiting for ACK
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. If you'd like to make up a patch and post it to the list, I can take care of it even sooner :) I have attached the output of: bzdiff -Naur \ /usr/share/man/man7/amanda-auth.7.bz2 \ ./amanda-auth.7.bz2 Thanks you for you help. CONFIDENTIALITY NOTICE: This electronic mail message and any attachment hereto may contain confidential information of Meyer Sound Laboratories, Incorporated and is intended for the personal and confidential use of the designated recipient(s) only. If you are not the intended recipient (or responsible for delivering the message to the intended recipient), you have received this message in error and any review, distribution, or copying of this message or any attachment hereto is prohibited. If you have received this message in error, please promptly notify the sender and permanently delete it from your computer. --- - 2010-02-01 12:12:28.674027472 -0800 +++ /tmp/bzdiff.xA8NsjfUIS 2010-02-01 12:12:28.0 -0800 @@ -41,7 +41,7 @@ \fBamdump\fR (amdump(8)) as well as the recovery process \fBamrecover\fR -(amrecover(8))\. For detailed information, please see http://wiki\.zmanda\.com/index\.php/Server/Client_authentication\;. +(amrecover(8))\. This man page is also available online, please see http://wiki\.zmanda\.com/man/amanda-auth\.7\.html .SH COMPILATION AND GENERAL INFORMATION .PP The communication method and thus type of authentication that will be used by the Amanda server is specified by the @@ -121,7 +121,7 @@ parameter selects a communication/authentication method to use between the client and the backup server\. These methods are described each in their own section below\. .SH BSD, BSDUDP, AND BSDTCP COMMUNICATION AND AUTHENTICATION .PP -For more detail, see http://wiki\.zmanda\.com/index\.php/Configuring_bsd/bsdudp/bsdtcp_authentication\;. +For additional information, see http://wiki\.zmanda\.com/index\.php/Configuring_bsd/bsdudp/bsdtcp_authentication .PP The
Re: selfcheck request failed: timeout waiting for ACK (with secondary addr on eth0 only)
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 (514) 340-4711 x5049 [EMAIL PROTECTED] - If God intended people to be naked, they would be born that way. -- Oscar Wilde -
selfcheck request failed: timeout waiting for ACK (with secondary addr on eth0 only)
Hello folks, I'm finally upgrading from the Amanda v2.4.x series to v2.5.2p1. My configuration worked fine with the old v2.4.x series... However, I'm having some strangeness with the new version... in particular with clients that have a primary and secondary ipaddr on the same interface (eth0). Here's an example: 2: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:23:e0:65:46 brd ff:ff:ff:ff:ff:ff inet 192.168.1.23/26 brd 192.168.1.63 scope global eth0 inet 192.168.1.25/26 brd 192.168.1.63 scope global secondary eth0 inet6 fe80::204:23ff:fee0: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 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 server is sending a request from the secondary address, but getting an answer from the primary address... and it doesn't seem to like it: clip ### 22:58:30.256184 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 153) amanda-server.909 secon-ip.amanda: UDP, length 125 [EMAIL PROTECTED].r...'`..?.Amanda 2.5 REQ HANDLE 000- SEQ 1204141709 end clip ### clip further down ### 23:02:51.877040 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 119) prim-ip.amanda amanda-server.577: UDP, length 91 [EMAIL PROTECTED]@.p.'`.A.c..Amanda 2.5 REP HANDLE 000- SEQ 1204602504 end clip ### I'd really like to get this to work... I use the secondary address in a dual-node cluster with Heartbeat-DRBD configuration. The secondary address is used for failover. Thanks in advance for your help. Luc Lalonde.
Re: selfcheck request failed: timeout waiting for ACK (with secondary addr on eth0 only)
Le vendredi 29 février 2008, Luc Lalonde a écrit : Hello folks, I'm finally upgrading from the Amanda v2.4.x series to v2.5.2p1. My configuration worked fine with the old v2.4.x series... However, I'm having some strangeness with the new version... in particular with clients that have a primary and secondary ipaddr on the same interface (eth0). Here's an example: 2: eth0: BROADCAST,MULTICAST,UP,1 mtu 1500 qdisc pfifo_fast qlen 100 link/ether 00:04:23:e0:65:46 brd ff:ff:ff:ff:ff:ff inet 192.168.1.23/26 brd 192.168.1.63 scope global eth0 inet 192.168.1.25/26 brd 192.168.1.63 scope global secondary eth0 inet6 fe80::204:23ff:fee0: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 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 server is sending a request from the secondary address, but getting an answer from the primary address... and it doesn't seem to like it: clip ### 22:58:30.256184 IP (tos 0x0, ttl 62, id 0, offset 0, flags [DF], proto 17, length: 153) amanda-server.909 secon-ip.amanda: UDP, length 125 [EMAIL PROTECTED].r...'`..?.Amanda 2.5 REQ HANDLE 000- SEQ 1204141709 end clip ### clip further down ### 23:02:51.877040 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto 17, length: 119) prim-ip.amanda amanda-server.577: UDP, length 91 [EMAIL PROTECTED]@.p.'`.A.c..Amanda 2.5 REP HANDLE 000- SEQ 1204602504 end clip ### I'd really like to get this to work... I use the secondary address in a dual-node cluster with Heartbeat-DRBD configuration. The secondary address is used for failover. Force the listen address in the relevant xinetd.d file. This will do the trick. -- Francis Galiegue, One2team - [EMAIL PROTECTED] [ATTENTION : CHANGEMENT DE COORDONNÉES !] +33178945552, +33683877875, http://www.one2team.com 40 avenue Raymond Poincaré - 75116 PARIS
