10.10.4 - mDNSResponder dying?

[chris_kemp]

We're starting to get reports of some machines failing to be able to connect to the internet after installing the 10.10.4 Delta update. One of the people affected is my boss, whose machine somehow started dying in the middle of our team call.

sudo killall -HUP mDNSResponder returns a "no such process" error;
ps -e | grep mDNSResponder shows no process running on his machine, whereas on mine it shows /usr/sbin/mDNSResponder.

Is anyone else seeing this? This is potentially very bad for our people...

[jjones]

We haven't seen this yet, but will keep a lookout as we have a large amount of systems now running 10.10.4

[bentoms]

@chris.kemp are you restarting after installing 10.10.4?

[chris_kemp]

I'd have to check with everyone, but I believe so. The issue is somewhat sporadic - we've had about 150 updates so far, with only a few reporting this problem. We thought it might have been localized to their office, until the boss' machine also quit. That gave us a chance to troubleshoot a bit more - but it's still really just a handful having this problem.

[SGill]

Getting no such process for 10.10.3 and /usr/sbin/mDNSResponder for 10.10.4 on the installs here….you might be looking a few upgrades that didn't actually fully complete...

[jjones]

Is there any similarities with them when it happens?

What version did they come from before 10.10, 10.10.2 and so on?
Are they all the same model?

Also did these machines happen to have the mdnsresponder fix ran on them before the 10.10.4 update?

[bpavlov]

I noticed you said you installed the delta update, why not install the combo update?

[JPDyson]

I've always deployed deltas by default, and reserved combos for shell cases or problematic updates. Makes sense to try it here.

[chris_kemp]

@Gillaspy We checked against discoveryd on the updated machines, and that was completely gone. The boss' machine was working since mid-day yesterday, so something has to have been handling DNS...

@jjones I believe everyone was on 10.10.3. Different models being affected. I'm wondering if the Combo would help, actually.

@bpavlov We didn't push it. :) These are users who went ahead & installed via Software Update. We posted about the update yesterday, saying we weren't yet recommending it but the users are free to update if they wished. Given the amount of trouble with 10.10 and discoveryd I'm not surprised so many people jumped.

We're discussing managing SUS right now, but at the moment we do not insert ourselves into the process.

[bpavlov]

Interesting @JPDyson I've always been told that combo updates are better for roll outs. Obviously in this case it wouldn't have made a difference since these were user initiated updates though.

[chris_kemp]

Combo update over his previously-updated MacBook Air did not fix. >:( Stay tuned...

[chris_kemp]

After doing the combo update we did:

sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist

and that apparently fixed things, at least for now. He's going to let it bake for awhile & see if it dies again - strange that it wasn't loaded after the update, but now he's back & the process shows up as expected.

[chris_kemp · Accepted solution]

SOLVED!

Turns out that the problem was with an older JAMF script, secureBonjour.sh that we were using as part of a security policy for a subset of our computers.

The old secureBonjour.sh script had a separate routine to allow for machines running 10.5 and before, that actually moved mDNSResponder to /Library/Application Support/JAMF/DisabledLaunchDaemons/.

It determined which routine to apply by using an $OS variable, which was set by the output of the command:

/usr/bin/defaults read /System/Library/CoreServices/SystemVersion ProductVersion | awk '{print substr($1,1,4)}'

The awk statement is the problem here, as it returns only 4 characters: it’s fine through 10.9, but when we get to 10.10 it returns only “10.1”, which triggers the pre-10.6 routine and removes the com.apple.mDNSResponder.plist file.

This would have been a problem as soon as we rolled out Yosemite, EXCEPT that Apple had already removed mDNSResponder – so the routine did nothing, UNTIL they put it back. :)

So the fix for us was to remove the $OS check and the pre-10.6 routine completely (which is fine, because we don't support anything pre-10.7 at this point).

Note that it is possible to edit the awk statement to

awk '{print substr($1,1,5)}'

which would return "10.10" - however, I can't say what that would return on pre-10.10 machines so that may not be a total fix either.

[mm2270]

Ah, bitten by that wonky OS version code. Its all over the place! It needs to be purged from every possible script out there at this point if you ask me.
I've been saying that the OS version check stuff in those older scripts isn't needed anymore for a while. I can't imagine there's anyone really supporting Macs running 10.5.x at this point. Interesting that this one escaped notice due to the fact that 10.10 initially removed mDNSResponder anyway.

I'm glad you figured it out and it wasn't something broken in 10.10.4.

[nesteph]

I haven't tested this on pre 10.7, but the following code returns the version of 10.X you are running. i.e., 10.10 would return 10, 10.9 would return 9, etc. Works a bit better than coding for a specific amount of characters in scripts.

sw_vers -productVersion | awk -F. '{print $2}'

[nessts]

or you could use perl and split

chomp(my $osver = `/usr/bin/sw_vers -productVersion`);
my @installed = split /./, $osver;
if ($installed[1] =~ /1[01]/) {
 do something useful
}

[Nix4Life]

Aw man @nessts

Every time I put of learning perl you give me 1 more reason to get to it

LS