Mac OS X Terminal not logging in

I am running Mac OS X version 10.6.3 and when I open the terminal (with terminal.app or iterm) it just hangs on the login process. I've tried restarting, changing the startup command to /bin/bash, and deleting the terminal preference file. All to no avail.

Solution 1:

It's possible that you have a bug in your .bashrc file... You can either try sticking echo statements in your .bashrc, or removing it, or trying tcsh instead of bash to see if that's the problem...

Solution 2:

I had a similar problem.
In my case, Terminal would stall saying 'Terminal — login — 80x24' in the title.

I didn't want to reinstall Terminal from OS X disk, and so I followed several different procedures, and in the end one of them seemed to have worked. I'm not certain which is most important, but I decided to share my exact steps in case someone finds them helpful:

1. Move com.apple.Terminal.plist away from ~/Library/Preferences/.

Some report that Terminal configuration file might get messed up and prevent the app from starting.
Move this file somewhere for backup, quit the Terminal and start it again.

In my case, resetting the configuration changed font and color settings to default, but the problem persisted. If so did yours, proceed to the step two:

2. Try running shell other than bash

Some advice to change default shell in the Terminal to /bin/zsh and restart the Terminal to see if the problem is specific to bash. In my case, doing so changed nothing, and the Terminal would still hang at login.

3. Try moving .bash* files away from home directory

I remembered that during previous session I created .bash_profile file in my directory. Perhaps something is really wrong with it. If you haven't created one yourself, some installer could've created (or edited) it, especially if the software is not specific to Mac OS.

Unfortunately, Finder doesn't show hidden files by default and doesn't provide an easy way to do this. However, in my case, I found that Automator could actually run bash commands successfully:

This is the script that I used:

cd ~

mkdir backup
for F in .bash*
do
    mv $F backup
done

It moved all files starting with .bash in my home directory to backup subdirectory.

4. Reboot

Restarting the app didn't work for me at this point but I decided to also give reboot a try.
After rebooting, Terminal worked. Voilà!

I moved the saved com.apple.Terminal.plist back to ~/Library/Preferences/, replacing the current one, and decided not to restore old (and somewhat not too useful) .bash* files and deleted backup directory.

I don't know whether it was a coincidence or a combination of specific steps that solved the problem but I'm glad that the Terminal is working again, and I hope yours will do so, too.

Solution 3:

If the current process really is "login", it usually means login is waiting to create a login session and hasn't even tried to start the shell yet. To verify this, look in Activity Monitor and see if you see the shell running or if you only see a "login" process. Note that if you have other terminals open, you may see other "login" and shell processes for them, so be careful about which processes you're examining. The trouble process is usually the latest one with the highest process id number (PID).

I realize Mark Szymanski said that rebooting didn't help in his case, but I thought I should mention this anyway: if it really is stuck in "login", the most common cause is that you ran "sudo" and then closed the terminal while it was waiting for you to enter your password. If you do this, sudo waits forever for the password and this blocks all logins until you kill the sudo process. The simplest way to resolve the issue is to reboot. Alternatively, you can kill sudo from Activity Monitor (or from another terminal if you happen to have one already open). As of Mac OS X Lion 10.7, sudo will notice when the terminal goes away and stops waiting for the password, so this problem should no longer occur.

Another cause of login delays is if you're connected to an Open Directory network and the directory server is sluggish or unresponsive. Report this to your network admin. This usually only causes delays of a few seconds, but in some cases they can last for up to several minutes.