I’ve written previously about how Apple dropped the turd that is Yosemite. It seems like every day I find more problems with Apple’s Macintosh operating system and server software. These aren’t just little niggling irritations, these are serious, drop-dead, should-have-been-caught-before-release bugs.
Apple brags about the millions of people that participated in its open beta test of OS X 10.10 Yosemite. I’m sure they all found the bugs I’m finding now and figured they’d be fixed by the time the software was released. Apple got what it paid for with its customers beta testing its operating system. What a mess.
In Yosemite itself, the latest bug that seems to be biting me almost constantly is the Computer Name being changed with an incremental number being added on seemingly any possible occasion. Consulting the Google reveals a plethora of supposed fixes for the problem, including the inevitable “I just spoke with an Apple engineer and he says…” bullshit. The fact is, that nothing so-far published remedies this serious problem and it’s been around in various guises for far, far too many years. Especially galling is that this problem has been reported to Apple for just as many years. Don’t think it’s a serious problem? Take a look at your Time Machine backups. Better yet, try to restore something.
Next up is a bedevilled change of some kind in OS X Server 4.0. Apple’s OS X 10.9.x/Server 3.x Mavericks came with Apache 2.2x and PHP 5.4x. With OS X 10.10/Server 4.0 Yosemite, Apple joined the modern age with Apache 2.4.x and PHP 5.5.x. Unfortunately, Apple configured one of its “special” — and by “special” I mean especially arcane — configuration files so that very long articles in WordPress won’t render. At all. All browsers throw an error, and only Google Chrome was remotely helpful: “Error code: ERR_EMPTY_RESPONSE.” It at least gave me a starting point.
Several days ago, I noticed that WordPress’s Jetpack was no longer indexing my server and providing related links at the bottom of each article. I spent days trying to resolve this issue myself and finally got Jetpack’s tech support involved. An email from one of the Jetpack Happiness Engineers (no shit) provided a clue:
“Likely what’s happening is that there is something weird about one of the posts in the next batch of posts. Maybe a wrong character encoding or maybe something else that breaks processing or json_encode.”
Well, if Jetpack can’t index the site, maybe Shiela Dixon’s absolutely indispensable Scrutiny can’t either and will at least give me some kind of error clue. Holy smokes, it’s been quite a while since I’ve upgraded Scrutiny; time to throw a few more dollars Shiela’s way.
Sure enough, Scrutiny was unable to access a handful of my website pages. The problem pages all had one thing in common: They were inordinately long (book excerpts, articles with which I got carried away, and the like).
The solution was relatively simple: Load those pages in the WordPress editor and add WordPress’s element after every screenful or so in each problem article. Be sure to remove any elements; they don’t play well with each other. Bingo, it worked on a couple of test pages I did.
Deactivate Jetpack’s Related Posts, run WP Clean Up to get rid of the old versions and other cruft, repair the WordPress database, optimize the WordPress database, activate Jetpack’s Related Posts, go to Jetpack’s debug page and watch how the re-indexing proceeds, back everything up, and genuflect, genuflect, genuflect.
I’ve managed to nudge Jetpack’s re-index completeness percentage from 44% to 58%, but unless I can get a specific filename that’s causing the hang-up, I’ve done all that I can do. I give up until Apple fixes this mess — it worked just peachy on OS X 10.9.x/Server 3.x. Apple’s missteps are the only variables.
So, thanks very much for once again changing something and not documenting it, Apple. You’re the best and your attention to quality is showing.
Thanks to Jon Schwenn writing at the indispensable StackExchange, the problem seems to be related to Apple’s not-quite-useless-but-dang-sure-more-trouble-than-it’s-worth Bonjour.
Be aware that this procedure will turn off Bonjour on any Mac(s) on which it’s performed. If you rely on Bonjour to discover devices and services on your local network — I’d ask why — understand that those devices and services will no longer be discoverable. If you think that’s a bad thing, move along; this isn’t the article for you.
Schwenn notes that OS X 10.10 Yosemite replaced mDNSResponder with discoverd. The relatively simple workaround is to turn off Bonjour in the /System/Library/LaunchDaemons/com.apple.discoveryd.plist file:
- Open the Terminal.app and enter the following commands:
- Using the Down Arrow key, scroll down to the Program Arguments section
- Add --no-multicast to the end of the Program Arguments section; the Program Arguments section of the /System/Library/LaunchDaemons/com.apple.discoveryd.plist file should look like this when complete:
<key>ProgramArguments</key> <array> <string>/usr/libexec/discoveryd</string> <string>--udsocket</string> <string>standard</string> <string>--loglevel</string> <string>Basic</string> <string>--logclass</string> <string>Everything</string> <string>--logto</string> <string>asl</string> <string>--no-multicast</string> </array> - Save the /System/Library/LaunchDaemons/com.apple.discoveryd.plist file
- Reboot your Mac
sudo nano /system/library/launchdaemons/com.apple.discoveryd.plist
Comments are closed.