The new way that can watch multiple paths - for versions 1.x and higher: fswatch -o ~/path/to/watch | xargs -n1 -I anywhere in your command.
Update: fswatch can now be used across many platforms including BSD, Debian, and Windows.
Inotify-tools package on most distributions) provides similar When an event about any change to that directory is received, the specified
MAC OS X WATCH DIRECTORY FOR CHANGES HOW TO
Unfortunately I can't remember how to set this up in Bind (I switched to djbdns years ago), but it should be possible.Fswatch is a small program using the Mac OS X FSEvents API to monitor a directory. My nf only contains a single nameserver entry, so I've never hit this particular problem. The cache machine sends local queries to the local DNS server and everything else to my ISP's DNS servers. What I've done here is to setup a DNS cache machine which all the local machines use as their DNS server. Since that server answers, you never get back to your internal server. So it looks like every time your system wakes from sleep, lookupd think its current nameserver choice has timed out and cycles to the next one. Yet another situation where 'ping foo' fails and 'host foo' succeeds. That seems to be consistent with the nf man page. The host and nslookup commands, on the other hand, always start each query with the first server listed. My suspicion is that latter.įrom playing around here, it looks like lookupd cycles throught the nameservers declared in /etc/nf until it finds one that works and then sticks with that nameserver until either it times out, or the modification date on /etc/nf is changed ('touch /etc/nf' as root is sufficient). That should at least tell you if it's a bind/sleep issue, or an Apple resolver/sleep issue. Out of curiousity, the next time your mac comes back from sleep, try running 'host some_machine your_mac' and see if you get a valid response. I do know that disabling Rendezvous completely had no affect on. That's probably why you installed a DNS server in the first place.įinally, I have no idea how this workaround might affect Rendezvous. local now resolve correctly, you've got the fun of keeping your /etc/hosts files in sync. LookupOrder Cache FF DNS NI DSThe tradeoff here is that while names in. The only other workaround I know of is to populate each Mac's /etc/hosts file with all the local IPs and hostnames (e.g., "10.0.0.1 foo"), and then change lookupd's search order with the following command (shown on two lines, but the backslash should allow a copy and paste to work): nicl. local domain, it was anything but simple (or pleasant). I've done that here, but with well-established kerberos and afs servers in the. Apple's recommendation is to simply change your domain from. This is documented in Apple's Knowledge Base (article 107174), but if you didn't think to browse the Rendezvous docs for DNS problems, you'd probably never find it. This gives the strange situation where nslookup returns the correct information while ping returns an 'unknown host' error. lookupd's DNSAgent simply refuses to issue queries for them. OSX (at least 10.2 and on) will not resolve. I found this the hard way, and since I see others have run into the same problem without listing a definite solution, I thought I'd make this easy to find.
0 kommentar(er)
