Terminal login hangs

Question

I have a strange issue on my new MacBook Pro (late-2016, touch bar).

It works fine and then, after using it for a while, opening new Terminal windows doesn't work because login hangs. Rebooting fixes the problem.

This seems to be an issue some other people have had so I tried all of their solutions already (from 1 and [2]):

1. Removing ~/Library/Preferences/com.apple.Terminal.plist
2. Setting my default shell to another shell (from /bin/zsh to /bin/sh or /bin/bash)
3. Removing or cleaning my .profile, .zprofile, ... This does not work and I can validate that the issue occurs before the shell is even invoked, because if I echo HEY as the first line of my .zshenv this is not even reached. It must be login causing the troubles. Editing /etc/profile to add an echo at the top also shows up nothing
4. Changing the Run command: setting in my Terminal config to something like echo foo also does not work (leaving Run inside shell checked or unchecked doesn't change anything).

Other notes:

• Like [2], ssh-add -K does not persist keys between reboots, something I never had troubles with before.
• The console does not show any suspicious errors or warnings.
• Opening a new Terminal window does seem to create tty file (/dev/ttys<number>).
• When this occurs, it does not matter if I use Terminal.app or iTerm.app
• I have a pretty clean install (just got my laptop, didn't restore any backups, just installed some apps with brew install and brew cask install).

This is really hard to debug because I cannot reproduce it and often I can't open a new terminal to even try to find out what's going on.

Does anyone have any tips?

Update:

Using iTerm, I was able to get a shell by setting the start command to /bin/bash. In this shell, however, sudo does not work. It hangs (without showing the prompt) and ctrl-C and ctrl-D do no work when it hangs.

Using some other programs also does not work in this shell: node or /usr/local/bin/node both hang. As far as I can tell, it's programs that are in/usr/local/bin.

Update 2:

brew list --full-name results in these packages:

autoconf
automake
blueutil
boost
cabal-install
cairo
cfssl
cmake
coreutils
doxygen
editorconfig
erlang
ffind
ffmpeg
flow
fontconfig
fontforge
freetype
gdbm
gettext
ghc
git
glib
go
gobject-introspection
graphicsmagick
harfbuzz
haskell-stack
highlight
icu4c
influxdb
jemalloc
jpeg
keybase
lame
libevent
libffi
libpng
libtermkey
libtiff
libtool
libuv
libvterm
libxml2
lua
mongodb
msgpack
nginx
node
openssl
openssl@1.1
pango
pcre
pixman
pkg-config
postgresql
protobuf
python
python3
rabbitmq
readline
reattach-to-user-namespace
redis
sqlite
the_silver_searcher
thefuck
tmux
unibilium
unixodbc
wxmac
x264
xvid
xz
yarn
z
zsh
josegonzalez/php/php54
neovim/neovim/neovim

Update 3:

These points are in correspondence with @Monomeeth's answer:

1. When it happens, a login item does show up in activity monitor. (Force) Quitting it also closes the Terminal window that was hanging. Closing the window manually does not make the login process go away in the Activity Monitor.

2. The terminal title is Terminal — login — term big — ttys001 — 89x18 — ⌘1, where term big is the settings name.

3. There's no sudo process showing up in the Activity Monitor. I can create a sudo process by opening iTerm.app (which uses bash) and running sudo echo ok there. It can not be Quit, but Force Quit works and kills it:

   bash-3.2$ sudo echo ok Killed: 9

Update 4:

When it happens, running login from a shell that's still available does work, while the login in newer shells seems to hang.

Update 5:

I recently got a new laptop (MacBook Pro 2017, no Touch Bar) and the problem persists.

I've switched shells as well: I'm now using fish with a pretty vanilla config. I think that rules out the shell as the culprit.

The OS has also been updated to 10.13.3 (17D47) High Sierra.

I've tried to install as little as possible on this machine:

brew list —-full-names

coreutils 8.29
dnsmasq 2.78
faac 1.29.9.2
fdk-aac 0.1.5
ffmpeg 3.4.1
fish 2.7.1
freetype 2.9
gdbm 1.14.1_1
gettext 0.19.8.1
git 2.16.1
highlight 3.42
htop 2.0.2_2
icu4c 60.2
imagemagick 7.0.7-22
jemalloc 5.0.1
jpeg 9b
lame 3.100
libav 12.2
libogg 1.3.3
libpng 1.6.34
libtermkey 0.20
libtiff 4.0.9_1
libtool 2.4.6_1
libuv 1.19.1
libvorbis 1.3.5_1
libvpx 1.7.0
libvterm 681
libyaml 0.1.7
lua 5.3.4_2
luajit 2.0.5
mongodb 3.6.2
msgpack 2.1.5
neovim 0.2.2
node 9.5.0
openssl 1.0.2n
opus 1.2.1
parallel 20180122
pcre 8.41
pcre2 10.30
postgresql 10.2
python 2.7.14_3
python3 3.6.4_2
readline 7.0.3_1
ripgrep 0.7.1
ruby 2.5.0
sqlite 3.22.0
the_silver_searcher 2.1.0
thefuck 3.25_1
unibilium 1.2.1
x264 r2795
xvid 1.3.5
xz 5.2.3
youtube-dl 2018.02.08

Not sure what this can be now. The only apps which I can think of are Divvy or Apptivate since they both seem outdated. This is the intersection of what was installed on the old vs the new machine:

coreutils
ffmpeg
freetype
gdbm
gettext
git
highlight
icu4c
jemalloc
jpeg
lame
libpng
libtermkey
libtiff
libtool
libuv
libvterm
lua
mongodb
msgpack
node
openssl
pcre
postgresql
python
python3
readline
sqlite
the_silver_searcher
thefuck
unibilium
x264
xvid
xz

Update 6:

Also, here's a screenshot:

Update 7:

My env typically looks like this:

Apple_PubSub_Socket_Render=/private/tmp/com.apple.launchd.k60Nf5UBfq/Render
DISPLAY=/private/tmp/com.apple.launchd.6FMoWPSlJI/org.macosforge.xquartz:0
EDITOR=env VIRTUAL_ENV= nvim -u /Users/john-doe/.config/vim/vimrc -p
GNUTERM=X11
HOME=/Users/romeo
HOMEBREW_NO_EMOJI=1
HOMEBREW_PREFIX=/usr/local
LANG=en_GB.UTF-8
LESS=-RI
LESSHISTFILE=-
LOGNAME=romeo
LS_COLORS=di=00;31:ex=00;37:mi=00;41;30:tw=00;33
MANPATH=/usr/local/opt/coreutils/libexec/gnuman
PAGER=less
PATH=/Users/john-doe/.config/fisherman/re-search:/usr/local/opt/python/libexec/bin:/usr/local/opt/ruby/bin:/usr/local/opt/coreutils/libexec/gnubin:/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/usr/local/MacGPG2/bin
PWD=/Users/romeo
SECURITYSESSIONID=186a8
SHELL=/usr/local/bin/fish
SHLVL=1
SSH_AUTH_SOCK=/private/tmp/com.apple.launchd.fQn5sHMuZP/Listeners
TERM=xterm-256color
TERM_PROGRAM=Apple_Terminal
TERM_PROGRAM_VERSION=400
TERM_SESSION_ID=D2AF7A50-8B41-4793-9201-8304A02C9B29
TMPDIR=/var/folders/15/zcyyfw_x7638z7vfg5zd85z40000gn/T/
USER=romeo
XDG_CACHE_HOME=/Users/john-doe/.cache
XDG_CONFIG_HOME=/Users/john-doe/.config
XPC_FLAGS=0x0
XPC_SERVICE_NAME=0

Answer 1

As I'm sure you know, troubleshooting is a process of elimination and often requires a fair bit of patience. I'd like to try a few things to try and get to the bottom of this for you.

1. Confirm it hangs during login

If the process it's hanging at is really during login, this implies that the process is still waiting to create a login session. Assuming this is the case, then it wouldn't have tried to start the shell yet.

To confirm this, the next time you experience this issue launch Activity Monitor to check if the shell is running or whether you only see a login process.

Once you've had a chance to do this, report back with what you found.

NOTE:- If you happen to have other terminals open, make sure you're checking the corresponding process. My guess is that the hanging process is the one with the highest Process ID (PID) number.

2. What is the Terminal title?

The next time you have this issue can you take a note of what the title of the Terminal window is and report back?

3. Kill sudo

You state that rebooting your MBP always resolves this issue.

However, the next time you have this issue (maybe after doing what I described at 1 above), I'd like you to try killing sudo from Activity Monitor.

Once you've tried this, let us know what happens.

4. Try moving your .bash* files

It is possible (for various reasons) you may have a .bash_profile file in your user directory and this is causing intermittent problems. This is something you may not even be aware of, but you can use Automator to run a script that finds and moves any .bash files.

Here is an example script for doing this:

cd ~

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

This script moves all files starting with .bash in your home folder to a newly created moved subfolder.

After running the script, check this folder and let us know if in fact you have any files in it.

NOTE:- You can label the new subfolder anything you want. To do so, just change the two occurrences of moved in the script to whatever label you'd like to use.

[UPDATE]

Some more things to try.

5. Try clearing the *.asl files

If you haven't already, try clearing out the *.asl files. To do this use the following:

sudo rm -rf /private/var/log/asl/*.asl

NOTE:- This may take some time as it creates a new shell. When complete, make sure you fully quit the Terminal for the changes to take affect.

6. Safe Mode

Do you notice any difference in behaviour when you start your MBP in Safe Mode? To boot into Safe Mode:

1. Fully shut down your Mac
2. Restart your Mac
3. Immediately press the Shift key and keep it down
4. Let go of the Shift key when you see the login window (NOTE: If you have FileVault enabled you may need to log in twice).
5. Once your MBP starts up try using Terminal and see if you can still replicate the issue?
6. When finished, you can exit Safe Mode by restarting your MBP as normal

7. Open Directory

This probably doesn't apply in your case since you don't mention it, but if you're connected to an Open Directory network this could also be causing you problems. Usually this would only entail waiting for about 10 - 15 seconds, but I have seen reports of terminal logins taking five or more minutes to complete in this situation.

Answer 2

This seems like a perfect fit for you exceeding the maximum processes per user (or possibly max processes).

On a stock macOS installation you get 709 per user (ulimit -u) and 1064 max processes (sysctl -a | grep maxp)

An easy way to bump these up is to install Server.app from the App Store and then reboot. You can also set performance mode for higher limits.

Since you didn't describe your setup (OS version and build), here are some tips - be sure to check for SIP restricting your ability to change files if you read some of the older articles on changing the limits without resorting to installing server.app:

• How do I increase "ulimit -u" (max user processes)?
• http://blog.dekstroza.io/ulimit-shenanigans-on-osx-el-capitan/
• https://support.apple.com/en-us/HT3854
• https://support.apple.com/en-us/HT4022
• https://serverfault.com/questions/15564/where-are-the-default-ulimits-specified-on-os-x-10-5

Answer 3

I have also been seeing this for several months now. Extremely frustrating. Only thing that fixes it is reboot.

• Mid 2015 MBP (no touch bar)
• MacOS 10.12.6 beta

Sometimes the login hangs happen after interacting with tmux.

I have unsuccessfully tried all the recommended approaches.

Not sure if it's related, but a lsof -p LOGIN_PID shows a pretty massive file /private/var/db/dyld/dyld_shared_cache_x86_64h for the hung login process.

8/29/2017 Update:

Still having the issue. Sometimes when the machine gets in the bad state, I have open terminal windows that are already logged in successfully that I can use to debug.

Many commands do not run properly, but they all show a pattern of having trouble writing (to stdout, I am thinking). For example, when I run ls -al, I see ls: write error emitted to stderr. When I run ls -al > /dev/null, nothing is printed to stderr.

Answer 4

It's important to treat the real issue and not just the symptom. So try out the following suggestions and update so based on that can suggest further remedies as well.

1. Which user owns the terminal?:
   My first hunch is that this can be related to how your account is set up. If terminal is trying to access the resources or directories that only the admin user can (if your's is a non admin account), then that can lead to freezing state - not allowing you to access the terminal. So go ahead and ensure when you begin a terminal session, it is local to your user and not another user. The fact that you cannot create a sudo process, is pointing me to this direction.

2. Type Control-Z or Command-Z:
   This control key sequence suspends a program that may be running and gives you a shell prompt. Now you can enter the jobs command to find the program’s name, then restart the program with fg or terminate it with kill.

3. Press Command-C:
   This will interrupt if the terminal is trying to run a program in the background. Try it a couple of times. Note if you see any output

4. Type Control-Q:
   If output has been stopped with Control-S, this will restart it.

5. Get an Alternative shell:
   If you want to try out a different shell for a few days, their behaviors may sometimes help you understand the problem with Terminal given if they act in a certain way. Check these links below for alternatives

https://git-scm.com/downloads/guis
https://computers.tutsplus.com/tutorials/beyond-terminal-4-os-x-terminal-alternatives--mac-56217

Will help to know the following, if not mentioned already:

• How are you initiating the terminal session? Is this via spotlight or a desktop icon or some other way?

• What is the terminal doing when it hangs? Is it in the middle of executing a command (Same command each time before it hangs) or it just hangs from the moment you start a terminal session/ windows.

• What do you usually use your terminal for? If a majority of your use is for git related commands only, I would suggest using Something like Github for Mac as you can usually do most of the things from there.

Answer 5

I would try to do disable SIP and dtrace login to find the root cause (To disable and re-enable SIP, see http://osxdaily.com/2015/10/05/disable-rootless-system-integrity-protection-mac-os-x/)

$ csrutil status
System Integrity Protection status: disabled.
$ cp /usr/bin/login /tmp
$ sudo dtruss /tmp/login

---

Trying to give you an example output, i just found out that things are much simpler than i thought. No need to disable SIP, just copy login.

dtuss will return the system calls and it might give a hint at where things go wrong.

cp /usr/bin/login .
sudo ls

give your password. Then do

sudo dtruss -d -e ./login 2> dtruss_login.txt

enter your username, press enter

enter your password, press enter

enter 'exit', press enter

and finally upload dtruss_login.txt to e.g. https://gist.github.com/

You can copy the contents of the file to the clipboard like this

cat dtruss_login.txt | pbcopy

You can find an example login here : https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

The second integer in each line is the time the call took.

Of course, it would be great if you could run this when the login hangs, but if I get you right, this is impossible.... maybe you or someone else has an idea on how to 'dtruss login' when the terminal hangs?

Answer 6

The login command source code has been published by Apple. The website is macOS 10.13.3 Source. The only required download is system_cmds-790.30.1. Once downloaded, the project can be easily modified to only build the login command. The modified project and logincommand have been place in GitHub at davidanderson61/system_cmds-10.13.3.

The idea here is to modify login to write debug information to the Console. This would help determine why the login command hangs. The modifications could be made anyone wishing to participate. I assumed this would have been me.

Install Debug login Command.

1. Select the latest release from the website davidanderson61/system_cmds-10.13.3/releases.

2. Download debug login command to your Downloads folder. Under "Assets", right click login and select "Download Linked File As", then select "Save".

3. Partially, disable System Integrity Protection (SIP). The command is given below. Before entering the command, you will need to boot to a macOS Recover, then a Terminal window.

   csrutil  enable  --without  fs
   

4. Enter the command given below to save original login command. If login.orignal already exists, you can omit this step.

   sudo  mv  /usr/bin/login  /usr/bin/login.original
   

5. Enter the commands given below to copy the debug login command and set the proper permissions.

   sudo  cp  ~/Downloads/login  /usr/bin/login
   sudo  chmod  104555  /usr/bin/login
   

6. Enable System Integrity Protection (SIP). Enter the following command. Afterwards, you should restart.

   sudo  csrutil  clear
   

Configure the Console Application

Below are the steps to configure the Console application to show only messages from the login command.

1. Open the Console application.

2. Add a PID column, as shown below.

   

3. Enter login in the Search field.

   

   While the the Search field has focus, press the return key. The Search field should change to what is shown below.

   

4. Change Any to Process, as shown below.

   

5. List Change Contains to Equals, as shown below.

   

6. Select the Save button. When prompted for "Save Search As:", enter Login, then select Save.

   

The results should appear as shown below. Next time you open the Console application, you will only have to select the "Login" button.

Appendix

How the GitHub Repository Was Created.

1. Click on the system_cmds.xcodeproj file open in Xcode.
2. From the menu bar, select Source Control->Create Git Repositories....
3. From the menu bar, select Product->Scheme->New Scheme.... Next, Select login as Target and Name.
4. From the menu bar, select Project->Build.
5. Quit Xcode.
6. Login at GitHub and create a new repository.
7. At the top of your GitHub repository's Quick Setup page, click to copy the remote repository URL.

8. For a Terminal application window, enter the following command. Replace <remote repository URL> with URL copied in the previous step.

   git  remote  add  origin  <remote repository URL>
   

9. Open the project in Xcode and from the menu bar, select Source Control->Push....

How the First Release Was Created

1. From a Terminal application window, enter the following commands.

   git  tag  -a  v1.0  -m  "Original source code"
   git  push  origin  v1.0
   

2. Copy the built login command to your Downloads folder.

3. From your GitHub account, create a new release as v1.0. Attach ~/Downloads/login as a binary.

Answer 7

I had this problem also while running sbt console in emacs. Whenever I exited out of sbt console by just killing the window instead of exiting out of sbt console "nicely" first, it caused a java process to hang even after the window was closed, and somehow prevented new terminal sessions from being created. I force-killed the java process from activity monitor, and the hanging terminal actually started, from within emacs as well as in a new tab.

Now, I just make sure to quit nicely using the command exit or ctrl-d (or ctrl-c ctrl-d in emacs term/multi-term), then kill the window.

Answer 8

1. Check if your process hangs really during login
2. Have a look on to the Activity Monitor and watch out for root processes (i.e. nano, emacs, vim) you might have initiated and not quit properly (crash, just killed the terminal, etc.) and which are still running.
3. Kill this process(es) and the login should work immediately.

Answer 9

Just my two cents.

I've installed the Terminus Package for Sublime Text, which allows me to run terminal within my text editor.

Closing Sublime Text immediately allowed my terminal to start working again.

Answer 10

FWIW, I had this same problem. It would resolve after reboot, but I wanted to save the time of doing that multiple times a day. It started after using a particular nodeJS environment, so I went into activity monitor and noticed a node process ongoing. Killing that instance solved the problem for me, so if anyone experiencing this has recently started working with node or npm locally, that could be your problem.

Answer 11

Killing a stray nvim instance fixed this for me. I assume this isn't specific to nvim but something nvim in my case was doing that caused problems. I would look for an out of place orphaned terminal app in activity monitor and kill that if you find one.

Answer 12

In my case, the new terminal window hung after displaying Last login: Tue Nov 24 18:31:39 on ttys001,and the title of the terminal window showed manpath.

Turns out that this happened because I had upgraded my Xcode from 11.7 to 12.2 but hadn't yet installed the new commandline tools. After starting Xcode and doing so, the terminal opened without problems or delays.