rang@cpsin3.cps.msu.edu (Anton Rang) (11/14/88)
Every once in a while I see the following scenario:
1. Mail is sent to some user (user@host.domain.domain).
2. Sendmail appears to hang for a while, way down in yp_match (I think).
3. Eventually, it times out (or something). The message bounces, with
the error "Deferred: address already in use" (or something like that.)
At this point, the message will go through if I try sending it again,
presumably because the information is now sitting in the local name
service cache. I assume there is some sort of timing (?) problem.
Can anyone explain this? Even better, is there a fix? I'm using
Sendmail 5.59 and Bind 4.8 (SunOS 3.4, YPSERV patch from Sun).
+---------------------------+------------------------+----------------------+
| Anton Rang (grad student) | "UNIX: Just Say No!" | "Do worry...be SAD!" |
| Michigan State University | rang@cpswh.cps.msu.edu | |
+---------------------------+------------------------+----------------------+sow@eru.mt.luth.se (Sven-Ove Westberg) (11/16/88)
In article <1070@cps3xx.UUCP> rang@cpswh.cps.msu.edu (Anton Rang) writes: |Every once in a while I see the following scenario: | | 1. Mail is sent to some user (user@host.domain.domain). | 2. Sendmail appears to hang for a while, way down in yp_match (I think). | 3. Eventually, it times out (or something). The message bounces, with | the error "Deferred: address already in use" (or something like that.) | |At this point, the message will go through if I try sending it again, |presumably because the information is now sitting in the local name |service cache. I assume there is some sort of timing (?) problem. | | Can anyone explain this? Even better, is there a fix? I'm using |Sendmail 5.59 and Bind 4.8 (SunOS 3.4, YPSERV patch from Sun). This is a known feature in the sun ypserv. I have reported it to hotline here in Sweden unfortunately they haven't find a fix yet. The problem is that if all name-servers for a region is unreachable for som reason. Then the ypserv tries forever. You can test it if you know a region without any servers. 1) Start debug on the nameserver. 2) Try to rlogin, telnet ... to an address in this region. 3) Look at the debug trace from the nameserver. This will never happen on a REAL unix eg bsd4.3 and if it had this kind of terrible bugs Berkeley would have sent out a fix promptly. Did Sun or some else have a fix to this problem??? Sven-Ove Westberg, CAD, University of Lulea, S-951 87 Lulea, Sweden. Tel: +46-920-91677 (work) +46-920-48390 (home) UUCP: {uunet,mcvax}!enea!cad.luth.se!sow ARPA: sow%cad.luth.se@ucbvax.berkeley.edu (only dumb ARPA mailers) Internet: sow@cad.luth.se Bitnet: sow%cad.luth.se@sekth
woods@ncar.ucar.edu (Greg Woods) (11/19/88)
In article <1280@luth.luth.se> Sven-Ove Westberg <sow@eru.luth.se> writes: >The problem is that if all name-servers for a region is unreachable >for som reason. Then the ypserv tries forever. > >..... > >This will never happen on a REAL unix eg bsd4.3 and if it had this >kind of terrible bugs Berkeley would have sent out a fix promptly. > >Did Sun or some else have a fix to this problem??? The fix is to obtain the sendmail and BIND sources (they are publically available via anonymous FTP from ucbarpa.berkeley.edu; I assume that anyone who really needs to use the name server has Internet access) and then link sendmail directly to the BIND resolver library, thus bypassing YP altoghether (HOORAY!) There is no reason to layer another level of software between sendmail and the name server. Another reason for doing this is that the version of BIND on which Sun based their in.named is known to have bugs. The latest version of BIND is 4.8 and is relatively stable. --Greg