Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

After installing MySQL 5.1.50 64-bit and running the package that configures MyQL to run at startup, the Terminal app now sporadically display a blank window, like so:

alt text

I managed to get the command prompt back after following the instructions from the MacFixIt column at CNET : OS X Terminal displays a blank window instead of a command prompt

However, the Terminal will intermittently go blank and I have to repeat the process again and it's driving me nuts. The CNET article cures the symtoms but the cause of this problem is still unknown. Does anyone has any theories or experiences to share in order to fix this annoying problem permanently?

share|improve this question
    
Have you solved this problem? –  JasKerr Oct 1 '10 at 11:24
    
It happened a few more times. Each time used the procedure suggested by CNET to fix it. Then it never happened again (so far). Wish I knew what caused it. Maybe Apple quietly push an update that fixed it. –  GeneQ Oct 1 '10 at 11:30
    
A common source of this is if you run sudo and then close the terminal while it’s waiting for you to enter the password. This hangs sudo, which prevents any further logins. To resolve the issue, use Activity Monitor (or another terminal if you happen to have one open) to kill the sudo process. (Obviously, if there is no sudo process, this isn’t the issue.) –  Chris Page Nov 3 '11 at 4:04
    
By the way, that C|Net article is incorrect about “…you can tell the terminal to specify the shell used and bypass the need to look up account information…” All shells and commands issued by Terminal are run via /usr/bin/login. All the UI is indicating is that the default shell is selected by /usr/bin/login (it looks at your user account info), but if you customize the shell, Terminal just tells /usr/bin/login to use that shell instead of the default. Login still must look up user account information to…login before running the shell or other command. –  Chris Page Nov 3 '11 at 4:07

4 Answers 4

A common cause for this is a hung "sudo" process. If you run sudo and it prompts for your password, but you close the terminal, sudo will hang forever waiting for the password, and this blocks any other logins until you kill it.

The solution is to kill the "sudo" process with Activity Monitor.

I believe sudo has been fixed on Mac OS X Lion 10.7 to exit if you close the terminal.

share|improve this answer

Try running jobs at the Terminal to see if that shell has any child processes in the background. If there is something super heavy running in the background maybe it is causing the shell to become unresponsive?

share|improve this answer
    
It hngs at the Unix login. (As the title bar of the Terminal shows). Some rights or authentication related stuff perhaps is causing the problem. –  GeneQ Aug 27 '10 at 10:24
    
Is it possible to investigate what is running after you get the prompt back but before it recurs? –  dtlussier Aug 27 '10 at 12:45

I just had the exact same problem, though it occurred after installing Git (or at least that is when I noticed the issue).

I opened the Activity Monitor and selected to show all processes. I noticed root was running several (> 10) login processes, few sh processes and a sudo process. I force-quitted them all, though some login processes didn't quit—probably the sudo kept them hanging. After this, Terminal worked normally and the excessive login processes I couldn't kill quitted.

I think the trick is to look for login and shell related processes which could hang new ones. Probably, in my case, killing the sudo would've been sufficient enough.

The CNet article you referred is good for a last resort.

share|improve this answer
  1. Launch Activity Monitor
  2. Select "All Processes, Hierarchically"
  3. Look for your Terminal process
  4. Try to spot a process that might be "stuck" and interfering with the login

Or:

  1. run fg in each active shell window

In my case, somehow git diff head had got put in the background in one of my shells, so git and less appeared under a shell in which I thought there was just a bash process. When I did fg it fixed the problem. If most of your windows/tabs are just "login -> bash" then it should be easy to spot.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.