|
Re: selfcheck request timeout
2008-01-23 10:49:47
Hi Marc, thanks for your ideas!
The system does indeed resolve it's full FQDN both through dig/nslookup,
but pinging the IP address does not resolve the hostname. Not sure if
this is an issue?
The output from your netstat command does indeed list the correct ports
and services listening from xinetd:
backup@zeus:/tmp$ netstat -taun | egrep :1008.
tcp 0 0 0.0.0.0:10082 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:10083 0.0.0.0:* LISTEN
udp 0 0 192.168.34.15:10080 0.0.0.0:*
This server is behind two firewalls and is on a non-routeable IP
subnet. As it's a homeLAN server, and doesn't get a whole lot of
traffic, I really have minimal security on this. As it's a Debian
derivative, SELinux is not enabled (if even installed) nor have I
installed anything to that effect.
Contents of amcheck debug file:
root@zeus:/var/log/amanda# cat amcheck.20080121221748.debug
amcheck: debug 1 pid 32409 ruid 34 euid 0: start at Mon Jan 21 22:17:48 2008
amcheck: dgram_bind: socket bound to 0.0.0.0.855
changer: got exit: 0 str: 1 9 1
changer_query: changer return was 9 1
changer_query: searchable = 0
changer_find: looking for NULL changer is searchable = 0
changer: got exit: 0 str: 1 /dev/nst0
amcheck: pid 32409 finish time Mon Jan 21 22:18:18 2008
Thanks for your help!!!
-Kermit
Marc Muehlfeld wrote:
Hi,
Kermit Short schrieb:
The client check mewls and cries, indicating the selfcheck request
timed out, and asks if the host is down.
Are all services through xinetd are running on your client/server?
# netstat -taun | egrep :1008.
tcp 0 0 192.168.29.2:10082 0.0.0.0:* LISTEN
tcp 0 0 192.168.29.2:10083 0.0.0.0:* LISTEN
udp 0 0 192.168.29.2:10080 0.0.0.0:*
> As the host is the same as the one running the check, it obviously
> isn't down.
Can you resolve the client/server name with FQDN? Setup in DNS or
/etc/hosts. Try using ping to resolve.
IPTABLES is not running on this host, so it isn't a firewall issue,
Maybe some other security feature like selinux, AppArmor,...
This one has me stumped, as the error logs don't even make a peep
that something in the system is even running, much less failing...
What is the content of your amcheck.*.debug logfile.
Regards
Marc
|
|
|
