In my experience, discoveryd is at best at about the quality of beta software. With some regularity on several different Macs on different networks, it completely loses the ability to resolve names. Kill it and let launchd restart it, and suddenly names resolve again.
Another Yosemite daemon addition, recentsd, had serious issues (for example: substantial memory leaks when interacting with Mail.app) until 10.10.2.
Apple has gotten very good at eliminating crashes. They're obviously using the reporting mechanism there to great effect. But at the same time, Console.app has never been noisier, and failures that don't result in crashes seem to linger far too long.
They've also become, it seems, far more dependent on an "orchestra" of daemon processes to perform tasks that in the past would have been implemented in passive frameworks used separately by each app. That adds complexity of coordination, and meanwhile a single failure can affect every "client" app on the system.
Then simply run `restart-discoveryd` when you can't seem to ping google.com. I always struggle to remember how to start/stop things with launchd, so this is my little shortcut.
I am not sure I understand what this command does, even after reading the man page for discoveryutil. Does it just restart any queries that have not been resolved, or does it restart the process as does my command? If it's the former, how does it work to fix whatever issues discoveryd is having?
In my short time poking around, my belief is discoveryd gets wedged into a state where it thinks DNS queries aren't resolving, and so it doesn't try to resolve them. I'm not sure what exactly is going on there, either all the queries are blocked somehow on some long-lived query that has no response and no timeout, or discoveryd thinks the network is broken and is waiting for it to come back (those are just guesses). Either way, the command tells discoveryd to restart any outstanding "questions" (which presumably means queries). When I had the issue, that was sufficient to flush out whatever it was that was blocking everything, as my machine instantly started working properly again.
Another Yosemite daemon addition, recentsd, had serious issues (for example: substantial memory leaks when interacting with Mail.app) until 10.10.2.
Apple has gotten very good at eliminating crashes. They're obviously using the reporting mechanism there to great effect. But at the same time, Console.app has never been noisier, and failures that don't result in crashes seem to linger far too long.
They've also become, it seems, far more dependent on an "orchestra" of daemon processes to perform tasks that in the past would have been implemented in passive frameworks used separately by each app. That adds complexity of coordination, and meanwhile a single failure can affect every "client" app on the system.