Relentless Inquiry

I’d been completely stumped earlier this year while attempting to try Second Life– the Mac client just “no va”, wouldn’t go, for me. I got an error suggesting that my DNS was busted and that I should try connecting to http://www.secondlife.com, and open a ticket if that didn’t work. How I was supposed to open said ticket if I had no IntarWebZ is left as a thought exercise, I suppose.

At any rate, after leaving it alone for the longest time, I was re-inspired to investigate this evening and found the problem. If I’d been a bit more Mac-savvy, I’d have found it long since– a good reminder that Mac OS is Not Unix, but something that Strongly Resembles Unix But With Quirks. Here is what I sent to the nice support folks at Second Life (who were quite helpful, but equally stumped along with me) this evening when I reopened the ticket:

I am reopening this so I can share the solution that I discovered with you. It turns out to be a very simple, yet very profound issue, and is easily diagnosed and corrected, so I want to be sure you add it to your solution base. It’s something to watch out for on folks running the Mac OS X client specifically.

Under Mac OS X, system applications, like Firefox, Safari, etc, use the built in resolver libraries. The Second Life client, like the nslookup utility, apparently is using classical DNS rather than the system libraries and using only /etc/resolv.conf to get information. The problem was that my /etc/resolv.conf file was no longer a link to /var/run/resolv.conf, and thsu was not supplying the correct information. This can happen for various reasons, including system updates, or booting without a network cable.

The symptom to identify this is if the person CAN get to http://www.secondlife.com from a browser, do ssh from a terminal/shell window, etc, but the Second Life client claims that there is a DNS error. This shows that the operating system is correctly doing name lookups via the built-in libraries, but that DNS is not correctly configured.

Diagnosis: Have the customer open up a terminal window and do “ls -l /etc/resolv.conf” and see if it is a symbolic link or a plain file. It should be a link to /var/run/resolv.conf.

Correction: If not, they should fix it: “sudo rm /etc/resolv.conf; sudo ln -s /var/run/resolv.conf /etc/resolv.conf”

If this does not resolve the problem, inspect the contents of /var/run/resolv.conf. If there is a problem with the network DHCP, there will not be any correct nameserver lines in the resolv.conf, and then that’s a client network problem not subject to quick fixes. 🙂

best regards,
Strata aka Maybear

See you online!