Runaway named process
Scott R. Presnell
srp at babar.mmwb.ucsf.edu
Tue Nov 20 06:44:23 AEST 1990
srp at babar.mmwb.ucsf.edu (I) write:
>Hi folks.
> I've got a curious problem with the name service that I can't seem
>to pin down. So I thought I'd ask to see if anyone else is having this
>problem.
>Over the last week, I've had several cases of the named process "running
>away:" gaining inordinate amounts of CPU time (in the thousands of minutes
Just in case someone else runs into this, I'll answer my own question.
Turns out that I got hit by the bogus root nameservers that are making the
rounds. If you see these guys in a named_dump.db of named, you've been hit
too.
; Dumped at Fri Nov 16 08:58:43 1990
; --- Cache & Data ---
$ORIGIN .
. 602116 IN NS NS.NIC.DDN.MIL.
[...]
18376 IN NS TELECOM. ; bad - does not exist
18352 IN NS NEXTSVR. ; bad
18352 IN NS MTECV1. ; bad
;
;
The affected hosts were secondary servers that forwarded requests. My
fix was two fold:
1) Don't be a named that forwards requests to a specific host (that,
in my case, caused the cache to become contaminated).
2) You may also want to get bind4.8.3 from ucbarpa.Berkeley.EDU
(ha, ha, they lost!) and install the named part. It takes no
effort to get it up on the SGI, and because you have the source,
you can insert code to warn you of cache changes and zone updates.
It's also a more recent version than the one SGI ships.
I'd be glad to help if anyone else bumps into this problem.
- Scott Presnell
--
Scott Presnell +1 (415) 476-9890
Pharm. Chem., S-926 Internet: srp at cgl.ucsf.edu
University of California UUCP: ...ucbvax!ucsfcgl!srp
San Francisco, CA. 94143-0446 Bitnet: srp at ucsfcgl.bitnet
More information about the Comp.sys.sgi
mailing list