/etc/resolv.conf not used on Mac OS X

[cdetrio]

Just a note for anyone trying to get focus.py working on OS X. Go to [ System Preferences -> Network -> Advanced -> DNS ] and there you can add 127.0.0.1 as your DNS server. Then focus.py will work.

[kjagiello]

I've just made a pull request with updated docs #10

[amoffat]

I'll post the question here (that I put on #10):

focus.py reads in the nameservers from /etc/resolv.conf, so that it knows which one to forward certain requests to. If Mac doesn't use resolv.conf, can you think of a good way for focus to know about the other nameservers?

[kjagiello]

As we have confirmed that it /etc/resolv.conf exists both on Mac OS X and Linux, should we remove the Mac OS X specific installation instructions from the readme?

[cdetrio]

I tried to explain the issue better on #10. Please keep the OS X instructions in the readme unless a solution other than the System Preferences dialogue can be found.

[amoffat]

@cdetrio I'm copying your comment in here, just so everything can be in one place...

The problem isn't focus.py being able to use /etc/resolv.conf. It is that the web browser (eg Chrome) does not resolve domains using resolv.conf ("most processes" as mentioned in the header), so even if 127.0.0.1 is in resolv.conf, the domain name requests made by the web browser never route to 127.0.0.1 (unless it is added to the DNS servers in the Mac system preferences) and therefore never to focus.py.

[amoffat]

Let me see if I understand correctly...

On the Mac, nothing actively uses resolv.conf. But when you update DNS servers in the system preferences, OS X updates resolv.conf with those new nameservers? So resolv.conf is basically just a record of what nameservers are being used (possibly for legacy apps)?

So if you add 127.0.0.1, this appears then in resolv.conf no? Or you have to add it to both? If you have to add it manually, where do the nameservers in resolv.conf come from then, if OSX isn't updating it?

[cdetrio]

@amoffat just did some testing and it appears you are right. Yes, adding 127.0.0.1 through system preferences, it then appears in resolv.conf ("manually generated", probably for legacy apps as you mention). And focus.py works, but the web browser ("most processes") is not using resolv.conf. I can remove the line "nameserver 127.0.0.1" from resolv.conf, and focus.py continues to work (the web browser is getting its nameservers from somewhere else, not resolv.conf).

[amoffat]

@cdetrio interesting. I think what is happening might be desired. Most processes, including web browsers, don't use resolv.conf directly. They do their DNS lookups by asking the operating system directly, and the OS replies by doing the lookups using the nameservers it knows about.

So if you start focus.py without 127.0.0.1 in resolv.conf, it shouldn't start at all (it should complain at you). If you don't have another nameserver besides 127.0.0.1 in resolv.conf, it should complain at you also. But after focus.py is started, you can change resolv.conf and it won't effect focus. If you remove 127.0.0.1 for example, OSX might not care, if resolv.conf is just a (possibly incorrect) record. In other words, OSX might not "forget" about 127.0.0.1 unless you remove it through system preferences...not through resolv.conf. Focus won't forget about nameservers in resolv.conf either, if it was edited after it was started.

Does this sound like it might be accurate?

[ergelo]

That is accurate in my experience. focus.py will not start unless there are other nameservers in the preference pane (and thus in the resolv.conf), and it will likewise not start if 127.0.0.1 is not specified as a nameserver.

[davidxia]

@amoffat I'm using Mac Lion and this is true:

So if you start focus.py without 127.0.0.1 in resolv.conf, it shouldn't start at all (it should complain at you). If you don't have another nameserver besides 127.0.0.1 in resolv.conf, it should complain at you also.

In System Prefs > Network > DNS, the name server IPs seem to be detected automatically. So when I ran into the 2nd problem of focus.py complaining that there weren't other nameservers, I manually added the IPs that were originally there.

But it's annoying to have to do this, and when I moved to another wireless network, the old IPs no longer worked. I had to remove all the IPs, get the dynamically picked up IPs, add back 127.0.0.1 and these IPs, and then restart focus.py. Is there a way to have focus.py not conflict with this default Mac Lion behavior that detects the appropriate nameserver IPs (i.e. not have to specify any other nameserver besides 127.0.0.1)?

[amoffat]

@davidxia I'm confused now. @cdetrio said that when he added an IP through the system preferences, it appeared in resolv.conf automatically. But from what you said, it sounds like resolv.conf isn't updated automatically when the system moves networks (and changes its nameservers). Can you confirm this?

I don't have access to a Mac, so this will be hard for me to understand and work up a solution. Essentially focus.py needs 2 things: to know about an existing nameserver, and for the OS to use 127.0.0.1 as a nameserver. The whole dance focus does with resolv.conf is to achieve these 2 things. But if Mac is not making it easy to do these 2 things, can you think of a way that might be easier?

[cdetrio]

I noticed the same issue as davidxia. I neglected to mention it since it seemed an idiosyncracy of OS X and not of focus.py. Eg, if you kill focus.py then you need to go to system preferences again and remove 127.0.0.1 for the browsers to work. Or alternatively, manually add the local router - then you wont have to come back to system preferences to add 127.0.0.1 for focus.py. Of course, that only works until you switch networks.

I don't know of an easier way than tinkering in system preferences. But its easy enough; this is now a meta-issue which distracts from utilizing and maintaining focus. closing issue.

[cdetrio]

@davidxia, There's a better workaround which is working for me: add 127.0.0.1, and then 8.8.8.8 (google's public DNS). 8.8.8.8 will work across different networks, so there shouldn't be a need go back into system preferences whenever you switch networks.

[davidxia]

@cdetrio Yea, I actually found this out a little while ago. Thanks.