I am getting the same behavior as Garrett.
I am running RedHat 7 with xinetd upgraded to "xinetd-2.1.8.9pre9-6" per
RedHat's
recommendations. I installed amanda-2.4.2.tar.gz from UW using all the
defaults.
After installing, I checked the following:
Defined amanda services:
$ grep amanda /etc/services
amanda 10080/udp # amanda backup services
kamanda 10081/tcp # amanda backup services
(Kerberos)
kamanda 10081/udp # amanda backup services
(Kerberos)
amandaidx 10082/tcp # amanda backup services
amidxtape 10083/tcp # amanda backup services
The "amanda" service itself:
$ cat /etc/xinetd.d/amanda
# default: off
# description: The client for the Amanda backup system.\
# This must be on for systems being backed up\
# by Amanda.
service amanda
{
socket_type = dgram
protocol = udp
wait = no
user = operator
group = disk
server = /usr/lib/amanda/amandad
disable = no
}
After a fresh restart of "xinetd" on all client machines, "amcheck"
finds no problems:
[root@yugo tom]# /etc/rc.d/init.d/xinetd restart
Stopping xinetd: [
OK ]
Starting xinetd: [
OK ]
[root@yugo log]# su - operator
[operator@yugo /root]$ amcheck -c DailySet1
Amanda Backup Client Hosts Check
--------------------------------
Client check: 2 hosts checked in 1.124 seconds, 0 problems
found
(brought to you by Amanda 2.4.2)
After "amdump" runs and fails, I find the following in /var/log/messages
on all client RedHat 7 machines:
Jan 2 17:36:12 carrera xinetd[11746]: xinetd Version
2.1.8.9pre11 started with
Jan 2 17:36:12 carrera xinetd[11746]: libwrap
Jan 2 17:36:12 carrera xinetd[11746]: options compiled in.
Jan 2 17:36:12 carrera xinetd[11746]: Started working: 6
available services
Jan 2 17:36:15 carrera xinetd: xinetd startup succeeded
Jan 2 17:37:27 carrera xinetd[11746]: amanda service was
deactivated because of looping
Jan 2 17:37:27 carrera xinetd[11746]: recv: Bad file
descriptor (errno = 9)
Jan 2 17:37:57 carrera amandad[11755]: error receiving
message: timeout
Jan 2 17:37:58 carrera amandad[11756]: error receiving
message: timeout
Jan 2 17:37:58 carrera amandad[11760]: error receiving
message: timeout
Jan 2 17:37:58 carrera amandad[11759]: error receiving
message: timeout
Jan 2 17:37:58 carrera amandad[11758]: error receiving
message: timeout
Jan 2 17:37:58 carrera amandad[11757]: error receiving
message: timeout
I don't know what this "looping" is about, but it appears that the
"amandad" service is
deactivated and there is always 6 dump processes that time out -
regardless of how
many filesystems there are to dump.
If anybody has an idea about this, I would appreciate a hint. This is a
show-stopper.
---
Tom Griffing, Vistyx Corp
[EMAIL PROTECTED]