Mac OS X: Removing Spurious SLP Entries
The Problem
Mac OS X sometimes sees duplicate and/or invalid listings of servers in the
"Local Network" (e.g. in the Finder's Connect to Server dialog box).
The Cause of the Problem
Mac OS X uses a protocol named SLP (Service Location Protocol) to find out what
services are available on the local network, and how to connect to them. For example,
when you use the Finder's "Connect to Server" feature, and select "Local Network", it
lists all servers on the local network that advertise themselves with SLP.
Unfortunately, the list of servers being advertised over SLP doesn't always
correspond with what's actually out there. It's fairly common (especially when
file serving is enabled on client computers that get their addresses via DHCP) for
the list to have some servers listed several times, and for some (or all) of the
entries to have invalid network addresses attached (so if you try to connect to them,
it can't actually reach them).
The root cause of the problem is that the SLP listings aren't being kept up to
date. If a computer's IP address changes (i.e. because the DHCP server assigned it
a new address), it may not stop advertising its services under the old address. It
also may not start advertising its new address; if it does, you get duplicate
listings, only one of which works; if it doesn't, you have just one entry, but it
doesn't work. If this sort of thing happens repeatedly, you can wind up with an
arbitrarily large number of invalid listings, and (if you're lucky) only one valid
one.
The Workarounds
I haven't found a way to completely avoid the problem (other than putting all
computers that provide any kind of service at static IP addresses), but the spurious
listings can at least be purged by hand.
What you need to do is track down each computer that's advertising itself
incorrectly, and force it to rebuild its SLP registration list. The cleanest way
I've found is to delete the list (kept in the file /private/var/slp.regfile) and
then reboot the computer.
This file's permissions are set so that no normal user can mess with it - you
need root access to delete it. One possibility is to enable your root account (see
Apple's knowledge base article
#106290), log in as root, and do the dirty deed. But logging in as root tends
to be dangerous (it's easy to destroy something you didn't intend to), and isn't
generally recommended. It's much better to give yourself root access just long
enough to delete the file, then go right back to normal. You can do this on the
command line by using the sudo
command. When you're logged into the computer as someone with administrative
access, open the Terminal and enter the command:
sudo rm /private/var/slp.regfile
It'll probably give you a short speil about acting responsibly (it does that the
first time you use sudo), and ask for your password (just to make sure you're really
you). If it takes the password and doesn't give any error, reboot the computer.
At this point, you should be done (at least with that particular computer). It's
a good idea to check the Local Network to make sure the spurious entries for that
computer are gone; if not, something went wrong somewhere.
If possible, you might also want to reconfigure your DHCP server to use longer
lease times on the addresses it hands out, or to otherwise prevent it from switching
the clients around so fast. This won't prevent the problem from reapearing, but
it should at least slow it down.
Additional Notes
If you're feeling adventurous, you can try editing the slp.regfile to remove just
the spurious entries. It's a text file, with a series of entries seperated by blank
lines. But you'll still need to reboot, and the valid entries will get rebuilt at
reboot, so there's not much point to this.
It may also be possible to reset the SLP services without rebooting; I've
experimented a but (mainly by using
kill -HUP on various
system daemons, but haven't been able to
get this approach to work reliably. If you figure it out, please let me know...
|