On my macbook, I've found that sometimes it gets into a state where it cannot open up a new terminal – a blank terminal window just appears, and it hangs. Rebooting solves this, but it seems to happen again within a week or so.
Activity monitor reveals that login is running, but it never gets to zsh as a child process. If I leave a terminal open, this terminal is still usable.
I can open a bash terminal on a different program, and in that case the system hangs if I run login, zsh, or, interestingly when I run ls /dev/tty*.
Even typing ls /dev/tty and hitting tab to autocomplete causes the terminal to hang and become unusable.
When these processes hang, the terminal is useless – CTRL-C does not stop them.
I suspect it is hanging on accessing /dev/ttys00*. It may be having trouble allocating a pseudo-tty? I don't think it is running out of available ptys because w only shows one or two open.
Here is some of the output from sample suggesting it is hanging on lstat:
Call graph:
2893 Thread_2786263 DispatchQueue_1: com.apple.main-thread (serial)
2893 start (in libdyld.dylib) + 1 [0x7fff5f9c43d5]
2893 ??? (in login) load address 0x105e34000 + 0x17b0 [0x105e357b0]
2893 ttyname (in libsystem_c.dylib) + 158 [0x7fff5fa3ba19]
2893 ttyname_r (in libsystem_c.dylib) + 146 [0x7fff5fa3baff]
2893 devname_r (in libsystem_c.dylib) + 175 [0x7fff5fa10e4d]
2893 lstat$INODE64 (in libsystem_kernel.dylib) + 10 [0x7fff5fafba0e]
Any ideas?
Best Answer
Had the same stack trace and killing nvim in activity monitor unblocked all the login processes. No idea why this worked, nvim was already orphaned so shouldn't have been running anyways.
Guessing the offending program is probably different for everyone though, so if you don't use nvim maybe just look for an out of place orphaned terminal app in activity monitor.