5

I've seen numerous cases of this all over the internet, and the solution is (optionally: Do _____ and then) reboot. The reboot is the only necessary step, but I'd like to remove that step (find the root of the problem). Here are the symptoms:

  • When I open Terminal.app, I see nothing except a cursor. No error text.
  • When SSHing, I get Timeout, server xxx.xxx.xxx.xxx not responding after a delay.
  • There are a lot of sshd processes running in activity monitor (over 30). Killing them does nothing.
  • Rebooting fixes it, but restarting Terminal.app does not.
  • Restarting Remote Login in System Prefs does nothing.
  • Console log shows nothing of significance when I open a new terminal.

I'm just looking for ideas. I know this isn't much to work with, but maybe someone has a brilliant idea of where to look. I know that this will be helpful to future users as I've seen many people with the problem:

Thanks!

1
  • 1
    Have you accedentally created a terminal script that starts each time you start terminal? Mar 30, 2012 at 23:34

1 Answer 1

1

If it never starts the terminal session even if you wait a few minutes, the most common cause of this is that the user closed a terminal while sudo was waiting for the password. On systems earlier than Mac OS X 10.7 Lion, this prevents any further logins until you either reboot or kill the sudo process. Use Activity Monitor to see if there is a sudo process and, if so, Force Quit it to clear up the problem.

In situations like this, the first thing to do is look at the terminal Inspector (Shell > Show Inspector) to see what processes are running in the terminal. If you see your shell or any programs other than login that means the login completed. In that case, the problem is likely due to something in shell startup files.

If it takes several seconds or a minute or two to start the terminal session because login is taking a while and you’re on a network with network user accounts, this can be caused by slow or unresponsive directory servers (or, more rarely, network communication flakiness).

Another issue that can cause login to take longer is if the system log has an inordinate amount of log data; it can take a few seconds for login to read the log to find the date/time of the last login so it can display the “Last login: …” banner. This can sometimes happen if there’s some systemic issue or specific program that’s causing thousands of log entries to be rapidly generated. This problem can be cleared up by deleting any large system log files found in /private/var/log/asl/. Some people simply delete everything with rm -rf /private/var/log/asl/*.asl, but I recommend specifically deleting only the latest log file and/or the largest.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .