When OSX loses its mind, pt 2: because lookupd has gone mad
So I posted previously about how OSX loses it mind: I can’t connect to the internet, can’t launch new applications (they just bounce endlessly in the Dock), my username - according to Activity Monitor - becomes “???”, services in the Terminal such as ping don’t work (even to local services, like the router), yet Appleshare does work. Trying to launch a new Terminal window gives the result seen in the picture. As I’m an administrator already, the only one who could have set my shell to an illegal value is root.
There have been plenty of comments, but having eliminated the possibility that it’s Menu Extra Enabler (let off: other people have similar problems but don’t have it installed) and .Mac’s keychain synchronisation (Eric sees this problem but doesn’t have it) and corrupted Keychain preferences (because how would that stop internet access?), we’re left with the most likely culprit: lookupd. Which, hey, runs with root privileges, and so could mess around with my “user id”. (While not preventing me doing things like taking screenshots..)
And there’s a thorny problem. It’s got a longstanding bug - known about since 2002, given the existence of the partial solution, unlockupd. Eric’s explanation -
My guess is that lookupd has gotten wedged in this scenario. Normally, if it crashes, it will exit and restart, because it is controlled by launchd. Sometimes, however, it will stop working, but not cleanly exit, meaning that it never gets respawned.
Lookupd mediates DNS lookups as well as connecting to Apple’s authentication system to log in to local resources. So, it fits with most of the symptoms. The AppleShare connection is governed by an external authentication system, so that is probably why it still works.
The intriguing thing is why more people don’t see this. Are there some circumstances that get in the way of lookupd dying cleanly, or restarting?
Simple. And all it needs is for Apple to fix it.
..tumbleweed..
..well, it’s been around since 2002 and nobody’s, you know, died. Can’t be that urgent, right?
- These posts might be related (the database thinks..):
- When OSX loses its mind: passwords don't work, internet dead, but Appletalk OK (29 December 2006; score: 68.26%)
- Why is nmblookup the kiss of death for OSX? (31 July 2007; score: 40.1%)
- How I learnt to stop worrying about reinstalling Tiger and stopped the March of Doom (21 June 2006; score: 39.31%)
![[Valid RSS]](wp-includes/images/valid-rss.png "Validate my RSS feed"){kind=small}
January 3rd, 2007 at 4:47 pm
I’ve been an Apple Consultant for years now and have NEVER seen this problem before with ANY of my clients.
Screwing with things you have no business putting your nose in will result in similar results…
January 3rd, 2007 at 5:02 pm
QUOTE:
I’ve been an Apple Consultant for years now and have NEVER seen this problem before with ANY of my clients.
Screwing with things you have no business putting your nose in will result in similar results…
REPLY:
My, what a blowhard you are…
I’ve been a pro system/network admin for over fifteen years, running across the gamut of operating systems from VMS, OS/400, all sorts of varieties of UNIX, Windows, MacOS, OS/2, you name it… I think I know what is a system problem and what is not, and this lookupd bug is REAL, but the conditions that seem to cause it are veiled in very heavy mists. I’ve seen it come and go on some systems, and others never have it. Even the systems that have run into it will just magically stop having the problem with no more interaction.
Just because YOU haven’t personally seen something, regardless of your “years of experience” does NOT mean that it doesn’t exist, nor does it mean that if it does exist it is because someone else is messing with things they ought not to. Sometimes the runup of conditions to cause something to happen is very peculiar, and you will never cause that set of conditions, but someone else will. That is also very likely why this bug still exists, Apple engineers aren’t magicians, and they can’t cause it to happen any more than you can unless they knew the EXACT runup conditions.
January 3rd, 2007 at 7:54 pm
My god, Jp, you’re right. What business does Mr Arthur have trying to use the computer he bought?
How dare he??
There’s no need to get all defensive and snotty whenever someone says something negative about Macs. Pretending problems don’t exist doesn’t help anyone.
January 3rd, 2007 at 8:52 pm
Just wondering if this might be fixed by running applejack in single user mode…
January 3rd, 2007 at 10:20 pm
Hi,
I had a problem way back cant even remember what it was (over 40 syndrome), installed this http://www.dshadow.com/software/unlockupd/ and never saw it again - maybe it will help
Steve
January 3rd, 2007 at 10:59 pm
Ah, @Steve Brown, bless you for trying. But I did mention
unlockupdin the post, because I’ve installed it.@GSKEnnedy, never heard of Applejack, but to be honest if I’ve gotten to single-user mode then I’ve already restarted, in which case I just want to get on and restart the machine. It always plays nice then until the next time it does it, which can be weeks, months, who knows.
Just to clarify my position: I don’t run root (it’s not enabled in Netinfo), so there’s no messin’ or pokin’ noses going on there. (Yes, how dare I turn it on and take pictures of the screen?) As SteveP says, it’s a very elusive bug which doesn’t cause a crash as such - more a sort of parallel condition where you can’t really do anything useful, unless you’ve got various developer tools open at the time.
January 4th, 2007 at 6:18 pm
Quote:
It always plays nice then until the next time it does it, which can be weeks, months, who knows.
Response:
I, unfortunately, apparently operate in the same mode. I have a MacBook Pro which I use every day at home and at work. For some reason I don’t reboot the sucker too often. I put it to sleep between connections at the office and at home and sometimes end up with a bunch of apps open. Eventually, after days or weeks, things turn to sh*t. Spinning beach balls and other havoc. Most of the time I am able to back out of the apps, saving the unsaved docs and reboot. But occasionally not. The IT guy at the office reminds me from time to time that computers do need to be rebooted. Memory leaks just happen and things go south with time.
Servers can stay up for long periods of time. They aren’t subjected to the same abuse as my laptop. Anyway, your comments serve to remind me that keeping our desktop or laptop computers up for weeks on end isn’t really helping me, or any other user, in the long run.
January 5th, 2007 at 3:36 pm
Err.. it’s helping me enormously, actually. I hate rebooting - all those browser windows to close, documents to save, useful pages or half-written scripts to decide whether to dump or preserve. I don’t even like logging out, for that reason. I’m in this for maximum uptime, baby. Which is why I hate this bug with a passion. Especially since it bit me last night and I had to hard reboot. My time is precious, my work more so, and my computer ought to be my servant. I ain’t logging out of nowhere for nobody without good reason.
March 5th, 2007 at 1:30 pm
I’ve get the same error with Terminal, but no other problems. I can launch it with an admin account, but not a standard account. I tested other Macs and found it affects the Intel Macs - fresh installs last week - but not the PPC Macs. (All 10.4.8, all network users). It does work fine on my Intel Mac at home with a local user account.
Not sure what to do about it as I just started learning Unix yesterday. It’s an issue with a shell, rather than Terminal, isn’t it? Any advice?
Thanks,
Brad
March 5th, 2007 at 11:50 pm
@brad - is Terminal configured to be allowed to run for those standard users? That would be a permissions issue. The way to see whether you’ve got the lookupd problem is to run “top” (no quote marks) in the Terminal - this gives you the same output as Activity Monitor, but less pretty. If you find a user with “????” then that’s the lookupd problem.
Not much to do that I know of except to reboot. That always fixes it in my experience.
March 8th, 2007 at 11:12 pm
Today I bound my Macintel to our site’s LDAPv3 service (previously was bound to my NIS domain). If I log in to my LDAP account, I see this problem with Terminal. If I log in to a local account, or my NIS account, Terminal is just peachy. Same physical home directory, uid, etc. in all cases. Reboots are not fixing it. Nothing logged anywhere. Stumped.
Apple’s X11.app xterm is working just fine in any case - and it’s so retro.
April 30th, 2007 at 4:12 pm
Just wanted to say I have trouble with lookupd as well. Brand new MBP ( March ‘07 ) and every once and a while it just starts consuming all of the CPU. 99% of the time I launch Activity Monitor and kill it ( takes some time to launch ).
All I can tell it that it seems to be getting worse, but I can’t quantify that.
May 2nd, 2007 at 10:35 am
@Eric - are you sure that’s lookupd? I’ve never seen it take any appreciable amount of CPU. And the characteristic of this problem that I have is that no app will launch - it bounces forever and then doesn’t appear, because lookupd does the authorisation for apps to run (ie checks that the user launching an app has permission to do so). When it’s gone loopy, it can’t confirm the permission, so no app will run. That’s why you can’t launch a new Terminal window, for example.
Personally I leave Activity Monitor running full-time now. It’s pretty light on the CPU, and the Dock readout tells you when there’s heavy weather.