Re: Strange DNS lookup problems ... I think ...
Hi, Geoff, on Montag, 08. März 2004 at 00:26 you wrote to amanda-users: GS Here's the output from the weekend: GS Subject:schedule6 AMANDA MAIL REPORT FOR March 5, 2004 GSDate: Fri, 5 Mar 2004 21:11:03 +1100 (EST) GSFrom:Amanda Archiving Server [EMAIL PROTECTED] GS To: [EMAIL PROTECTED] In your first email you wrote: The amanda host machine is windamere Why does your report come from dipnr.nsw.gov.au then? GS These dumps were to tape schedule6-WEEK2. GS The next tape Amanda expects to use is: schedule6-WEEK3. GS FAILURE AND STRANGE DUMP SUMMARY: GS intrap /htdocs lev 0 FAILED [ [host GS windamere.dlwc.nsw.gov.au: hostname GS lookup failed]] Please show us your disklist entry for this one. GS NOTES: GS planner: tapecycle (6) = runspercycle (6) You added two tapes, but you still have these two parameters on the same value. tapecycle should be BIGGER THAN runspercycle. GS planner: Last full dump of intrap:/htdocs on tape overwritten in 1 run. Lost your last full dump here ... GS intrap /appl 0 12363201236320 --3:395636.7 6:493020.1 GS intrap /htdocs 0 FAILED GS --- As one DLE works and another on the same host does not work, it is very likely that the setup of the DLE is not right. Show us your disklist and the relevant dumptypes. Did this one ever work? -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
Re: Strange DNS lookup problems ... I think ...
I read the last e-mail about this, but lost it, but I think I remember the basic details. First, I would try setting up some sort of nameservice caching on the client and server as a work-around. Some flavors of Linux have a caching-nameserver package that sets up the correct bind files for you, then you just put nameserver 127.0.01 at the top of /etc/resolv.conf. tmdns is supposed to be a more lightweight caching nameserver of some sort, but I haven't had good luck with it so far. nscd is a more general-purpose nameservice caching mechanism that can also cache NIS and LDAP data, but I think there may be a kernel piece to it that you also need compiled into the kernel. SGI IRIX has nsd which is similar to nscd. If you use nscd or nsd, check /etc/nsswitch.conf for the order that name services will be checked for hosts. In particular, you may need to delete nis+ or nisplus if you don't have NIS+ running on your network--It is often in there as one of the defaults, but can cause the host res process to crap out at that point if you don't have NIS+ available on your network. Second, I would check interface statistics on the client, server, nameserver, and switches and routers if possible. You want to check for collisions and/or errors, and keep an eye out for duplex mismatch or auto-negotiation problems related to certain hardware. Watch out for misbehaving mini-hubs or mini-switches along the way. I have had problems with interface hotplug on Linux and certain cards not detecting a link or auto-negotiating correctly, eg. 3c509B. I had to put MII_NOT_SUPPORTED=yes in /etc/sysconfig/network-scripts/ifcfg-ethX where X is the number of the interface, to explicitly disable hotplug for that adapter. --jonathan
Re: Strange DNS lookup problems ... I think ...
hi all ... thanks for the reply's so far
I know the reverse lookups are fine (see original email) ... to add some
more info that might help, look at this weekends results there are 8
filesystems in the schedule ... 8 of them work ... and ONE of them gets the
error ... one can only assume that maybe there is a DNS timeout in the
code. The other 7 worked fine. I know the host gets pretty loaded up ...
it's feeding 5 AIT tape drives and the disks are working at about 15-20MB /sec
when they are feeding the 5 tape drives. Maybe it's a timeout??
Here's the output from the weekend:
Subject:schedule6 AMANDA MAIL REPORT FOR March 5, 2004
Date: Fri, 5 Mar 2004 21:11:03 +1100 (EST)
From:Amanda Archiving Server [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
These dumps were to tape schedule6-WEEK2.
The next tape Amanda expects to use is: schedule6-WEEK3.
FAILURE AND STRANGE DUMP SUMMARY:
intrap /htdocs lev 0 FAILED [ [host windamere.dlwc.nsw.gov.au: hostname
lookup failed]]
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:04
Run Time (hrs:min) 2:11
Dump Time (hrs:min)1:36 1:36 0:00
Output Size (meg) 19176.819176.80.0
Original Size (meg) 19176.819176.80.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped7 7 0
Avg Dump Rate (k/s) 3405.0 3405.0--
Tape Time (hrs:min)1:45 1:45 0:00
Tape Size (meg) 19176.819176.80.0
Tape Used (%) 26.8 26.80.0
Filesystems Taped 7 7 0
Avg Tp Write Rate (k/s) 3105.1 3105.1--
USAGE BY TAPE:
Label Time Size %Nb
schedule6-WEEK2 1:45 19176.8 26.8 7
FAILED AND STRANGE DUMP DETAILS:
/-- intrap /htdocs lev 0 FAILED [ [host windamere.dlwc.nsw.gov.au: hostname
lookup failed]]
\
NOTES:
planner: tapecycle (6) = runspercycle (6)
planner: Last full dump of intrap:/htdocs on tape overwritten in 1 run.
taper: tape schedule6-WEEK2 kb 19637248 fm 7 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
intrap / 0 28156482815648 --7:076599.7 15:023123.1
intrap /appl 0 12363201236320 --3:395636.7 6:493020.1
intrap -xport/home 0 437184 437184 --0:587507.5 2:302915.7
intrap /htdocs 0 FAILED ---
intrap /opt0 14208641420864 --4:095717.6 7:363115.5
intrap /opt/apache 0 47804484780448 -- 24:173281.8 25:333118.1
intrap /u010 57900805790080 -- 48:191997.2 31:043106.2
intrap /u020 31564803156480 --7:396882.0 16:503124.9
(brought to you by Amanda version 2.4.4p2)
Jonathan Dill wrote:
Resolving IP address to a hostname (reverse lookup) is the part that
looks broken, check the reverse domain in the DNS i.e.
host 172.24.16.86
or
nslookup 172.24.16.86
The error says *hostname* lookup failed, not address lookup failed.
Someone else reported a similar problem a few days ago, and he reported
that there was a typo in the reverse domain file of the DNS, and that
fixing that fixed the problem.
I wonder though, Why does amanda need to do a reverse lookup? You give
amanda a hostname in the DLE, and it looks up the IP address, which
should be adequate for amanda to do what it needs to do. But then it
tries to do a reverse lookup for the hostname based on the IP address,
and gives up if that fails.
It would be nice if the reverse lookup could be avoided. In principle,
yes, the reverse table in your DNS should be correct, but failing backup
seems like an expensive DNS diagnostic.
planner: ERROR intrap: [addr 172.24.16.86: hostname lookup failed]
--jonathan
--
geoffs :-)
--
Geoff Swavley Email : [EMAIL PROTECTED]
UNIX Sys Admin Snail : Level 8, 10 Valentine Ave,
Support and Network Operations Parramatta NSW 2150
Dept of Infrastructure, PlanningSydney Australia
and Natural Resources Phone : 61-2-98957125
http://www.radx.net/~geoffs Fax : 61-2-98957086
Mobile: 61-422-002005 Home : 61-2-96593637
--
Be wary of the man who urges an action in which he himself incurs
no risk. - Setanti, Joaquin de
Re: Strange DNS lookup problems ... I think ...
Resolving IP address to a hostname (reverse lookup) is the part that looks broken, check the reverse domain in the DNS i.e. host 172.24.16.86 or nslookup 172.24.16.86 The error says *hostname* lookup failed, not address lookup failed. Someone else reported a similar problem a few days ago, and he reported that there was a typo in the reverse domain file of the DNS, and that fixing that fixed the problem. I wonder though, Why does amanda need to do a reverse lookup? You give amanda a hostname in the DLE, and it looks up the IP address, which should be adequate for amanda to do what it needs to do. But then it tries to do a reverse lookup for the hostname based on the IP address, and gives up if that fails. It would be nice if the reverse lookup could be avoided. In principle, yes, the reverse table in your DNS should be correct, but failing backup seems like an expensive DNS diagnostic. planner: ERROR intrap: [addr 172.24.16.86: hostname lookup failed] --jonathan
Re: Strange DNS lookup problems ... I think ...
hi geoff,
i've had a similar problem about a week ago. look at this report-snippet
(i've taken out the hosts and ip's):
--
These dumps were to tape daily09.
The next tape Amanda expects to use is: a new tape.
The next new tape already labelled is: daily10.
FAILURE AND STRANGE DUMP SUMMARY:
nptn.some.net /var/lib/mysql_backup lev 0 FAILED [nptn.some.net:
[addr 1.2.3.4: hostname lookup failed]]
nptn.some.net /etc lev 0 FAILED [nptn.some.net: [addr 1.2.3.4:
hostname lookup failed]]
nptn.some.net /home lev 0 FAILED [nptn.some.net: [addr 1.2.3.4:
hostname lookup failed]]
--
also in my case, it's very unlikely that it's a dns issue. we run our
own nameservers, and none have had any downtime. forward and reverse is
also properly configured..
i have no answer to your question, but in my case the problem seems to
have fixxed itself.. the next day this host was backed up properly, and
i've had no problem since. maybe amanda's dns lookup process is a bit
flakey?
regards,
-Rodi Evers
On Fri, 2004-03-05 at 04:44, Geoff Swavley wrote:
hi All,
I run 25 schedules per night, and only 1 ... this one ... gives me some
heart-ache. I know it must be something other than DNS but all of the
error messages are trying to send me down that garden path. The amanda
host machine is windamere, and schedule6 backs up intrap. I can log onto
both machines and easily do forward and reverse lookups on both hosts, so I know
there is no DNS issue.
---
windamere[26]% nslookup intrap
Server: gps.dlwc.nsw.gov.au
Address: 172.24.16.91
Name:intrap.dlwc.nsw.gov.au
Address: 172.24.16.32
windamere[27]% nslookup 172.24.16.32
Server: gps.dlwc.nsw.gov.au
Address: 172.24.16.91
Name:intrap.dlwc.nsw.gov.au
Address: 172.24.16.32
windamere[28]%
--
intrap[1]# nslookup windamere
Server: gps.dlwc.nsw.gov.au
Address: 172.24.16.91
Name:windamere.dlwc.nsw.gov.au
Address: 172.24.16.86
intrap[2]# nslookup 172.24.16.86
Server: gps.dlwc.nsw.gov.au
Address: 172.24.16.91
Name:windamere.dlwc.nsw.gov.au
Address: 172.24.16.86
intrap[3]#
Here's the output from the schedule 6 dump - planner is NOT HAPPY
about something any ideas what's going wrong???:
Subject:schedule6 AMANDA MAIL REPORT FOR March 5, 2004
Date: Fri, 5 Mar 2004 00:15:07 +1100 (EST)
From:Amanda Archiving Server [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
These dumps were to tape schedule6-THU.
The next tape Amanda expects to use is: schedule6-MON.
FAILURE AND STRANGE DUMP SUMMARY:
planner: ERROR intrap: [addr 172.24.16.86: hostname lookup failed]
intrap / RESULTS MISSING
intrap /appl RESULTS MISSING
intrap /export/home RESULTS MISSING
intrap /htdocs RESULTS MISSING
intrap /opt RESULTS MISSING
intrap /opt/apache RESULTS MISSING
intrap /u01 RESULTS MISSING
intrap /u02 RESULTS MISSING
STATISTICS:
Total Full Daily
Estimate Time (hrs:min)0:00
Run Time (hrs:min) 0:00
Dump Time (hrs:min)0:00 0:00 0:00
Output Size (meg) 0.00.00.0
Original Size (meg) 0.00.00.0
Avg Compressed Size (%) -- -- --
Filesystems Dumped0 0 0
Avg Dump Rate (k/s) -- -- --
Tape Time (hrs:min)0:00 0:00 0:00
Tape Size (meg) 0.00.00.0
Tape Used (%) 0.00.00.0
Filesystems Taped 0 0 0
Avg Tp Write Rate (k/s) -- -- --
USAGE BY TAPE:
Label Time Size %Nb
schedule6-THU 0:00 0.00.0 0
NOTES:
planner: tapecycle (4) = runspercycle (4)
driver: WARNING: got empty schedule from planner
taper: tape schedule6-THU kb 0 fm 0 [OK]
DUMP SUMMARY:
DUMPER STATSTAPER STATS
HOSTNAME DISKL ORIG-KB OUT-KB COMP% MMM:SS KB/s MMM:SS KB/s
-- -
intrap / MISSING --
intrap /appl MISSING --
intrap -xport/home MISSING --
intrap /htdocs MISSING --
intrap /opt MISSING --
intrap /opt/apache MISSING --
Re: Strange DNS lookup problems ... I think ...
Hi, Geoff, on Freitag, 05. März 2004 at 04:44 you wrote to amanda-users: GS NOTES: GS planner: tapecycle (4) = runspercycle (4) GS driver: WARNING: got empty schedule from planner GS taper: tape schedule6-THU kb 0 fm 0 [OK] I would try to correct the issue mentioned here first. Add tapes to this cycle so that tapecycle is at least 5 in this case. Could be that planner does not plan if tapecycle = runspercycle as one might guess from the second line above. -- How does your disklist look like? Do you use intrap or intrap.dlwc.nsw.gov.au there? AFAIK the first ... -- best regards, Stefan Stefan G. Weichinger mailto:[EMAIL PROTECTED]
