Determining which process is generating DNS queries to "old" nameserver
Brandon Hutchinson
We've looking to retire a nameserver in our environment. We've made
changes to the Solaris clients' /etc/resolv.conf, but some processes
are still sending DNS requests to this "old" nameserver.
We've restarted several system processes (e.g., autofs, nfs.client,
syslog, sendmail, ldap.client, etc.), but something is still
referencing the "old" nameserver.
Is there a way to determine which process is responsible for this
traffic? dtrace is unfortunately not an option, as in this case the
Solaris systems are not running Solaris 10.
Any other solutions using truss or lsof? We can of course reboot the
systems as a last resort.
Thanks in advance!
Brandon
tkevans
snoop
Richard B. Gilbert
I don't think you have reboot the whole server. See the man page for
"kill" with special attention to "kill -1". I think that will restart
the application and cause it to reread any initialization files.
If worst comes to worst you can use sys-unconfig (see the man page for
it) and redo your configuration. That wipes the existing configuration
and does a reboot after which you will be asked for a new configuration
just as you were when you first installed Solaris.
Before you start be sure that you know the correct node name, IP address
or addresses, the date, time,. . . . Go thou and RTFM. It's all in there.
Brandon Hutchinson
>
> I don't think you have reboot the whole server. See the man page for
> "kill" with special attention to "kill -1". I think that will restart
> the application and cause it to reread any initialization files.
>
> If worst comes to worst you can use sys-unconfig (see the man page for
> it) and redo your configuration. That wipes the existing configuration
> and does a reboot after which you will be asked for a new configuration
> just as you were when you first installed Solaris.
>
> Before you start be sure that you know the correct node name, IP address
> or addresses, the date, time,. . . . Go thou and RTFM. It's all in there.
I may not have been clear in my original post, but I know which
systems are generating the DNS traffic to the "old" /etc/resolv.conf
nameserver entries. I want to find out which process(es) on these
systems are generating this DNS traffic so I can restart them.
We may end up just rebooting these systems, but I was wondering if it
is possible to figure this out using lsof, truss, etc.
Thanks,
Brandon
Horst Scheuermann
look for nscd svc:/system/name-service-cache:default
--
12. Gebot: Wenn Ihr eine Fahrradklingel hört, wechsele die, die links geht
nach rechts, die die rechts geht nach links, aber nicht bis zum Straßenrand.
Danach dreht Euch um, reißt Mund, Nase und Augen auf, tretet aber keinesfalls
zur Seite.
Colin B.
Not really a 'how to' answer, but are you running any of Sun's messaging
products (webmail, ims, etc.)? We've found that most of them will read
resolv.conf at start-time, and then cache the information.
That would be my guess: Sun products that aren't part of a base install.
As far as I've ever seen, any part of the normal OS infrastructure
(syslog, nfs, nis, sendmail, etc.) will behave as expected, and parse
resolv.conf as used.
I assume you've scoured the logfiles. If you're willing to risk breaking
(temporarily) the mystery application, you could use IPF (most likely on
the old nameserver) to block port 53 from one host, and see what complains.
I would HOPE, at least, that the rogue applications would send up a flag
if they couldn't resolve hostnames.
Colin
Richard B. Gilbert
Yes, you can hope, but one misfeature implies another! Or, where
there's one bug, suspect an infestation!
hume.sp...@bofh.ca
> We've looking to retire a nameserver in our environment. We've made
> changes to the Solaris clients' /etc/resolv.conf, but some processes
> are still sending DNS requests to this "old" nameserver.
Would the content of the requests give any hint as the application making
the query? snoop should show what's being asked for.
--
Brandon Hume - hume -> BOFH.Ca, http://WWW.BOFH.Ca/
Darren Dunham
> Not really a 'how to' answer, but are you running any of Sun's messaging
> products (webmail, ims, etc.)? We've found that most of them will read
> resolv.conf at start-time, and then cache the information.
That's going to be true of just about any process on a machine where
nscd is not running.
> That would be my guess: Sun products that aren't part of a base install.
> As far as I've ever seen, any part of the normal OS infrastructure
> (syslog, nfs, nis, sendmail, etc.) will behave as expected, and parse
> resolv.conf as used.
I think that is only true if nscd is running before the program is
launched.
--
Darren
Brandon Hutchinson
Thanks everyone for the responses. We're not retiring this name server
for a few weeks, so I have the luxury of trying to figure this out
without a reboot. It's really just a problem I found "interesting." A
reboot makes the most sense.
The systems using the "old" name server are running Solaris 8. nscd
was one of the system processes that I looked for an restarted when
troubleshooting this problem.
Surprisingly (at least to me), restarting cron took care of most of
the remaining traffic; DNS traffic to the old name server seemed to be
generated when cron was running /usr/lib/sa/sa1 to collect sar data.
I now have pretty much everything off the old name server, and if I
can't figure out the remaining items, I'll just reboot the systems.
I was wondering if running lsof in a loop or something similar would
be able to identify these processes referencing the old name server,
but my attempts so far have failed.
Best regards,
Brandon