Mam dziwny problem z moim nowym MacBookiem Pro (koniec 2016 r., Pasek dotykowy).

Działa dobrze, a następnie, po dłuższym użyciu, otwieranie nowych okien terminala nie działa, ponieważ loginzawiesza się. Ponowne uruchomienie rozwiązuje problem.

Wydaje się, że jest to problem, który mieli inni ludzie, więc wypróbowałem już wszystkie ich rozwiązania (z 1 i [2] ):

1. Usuwanie ~/Library/Preferences/com.apple.Terminal.plist
2. Ustawianie mojej domyślnej powłoki na inną powłokę (od /bin/zshdo /bin/shlub /bin/bash)
3. Usuwanie lub czyszczenia mój .profile, .zprofile... To nie działa i mogę potwierdzić, że problem występuje, zanim powłoka jest nawet powoływać, bo gdybym echo HEYjako pierwszej linii mój .zshenvnie jest jeszcze osiągnięta. To musi loginpowodować problemy. Edycja /etc/profiledodająca echo u góry również niczego nie pokazuje
4. Zmiana Run command:ustawienia w mojej konfiguracji terminala na coś podobnego echo foorównież nie działa (pozostawienie Run inside shellzaznaczonego lub niezaznaczonego niczego nie zmienia).

Inne notatki:

• Podobnie jak [2] , ssh-add -Knie przechowuje kluczy między restartami, z czym nigdy wcześniej nie miałem problemów.
• Konsola nie wyświetla żadnych podejrzanych błędów ani ostrzeżeń.
• Otwarcie nowego Terminalokna wydaje się tworzyć plik tty ( /dev/ttys<number>).
• Gdy to nastąpi, nie ma znaczenia, czy korzystam z Terminal.app lub iTerm.app
• Mam dość czystej instalacji (właśnie dostałem laptopa, nie przywróci żadnych kopii zapasowych, tylko niektóre aplikacje zainstalowane z brew installa brew cask install).

Naprawdę trudno to debugować, ponieważ nie mogę go odtworzyć i często nie mogę otworzyć nowego terminala, aby nawet spróbować dowiedzieć się, co się dzieje.

Czy ktoś ma jakieś wskazówki?

Aktualizacja:

Korzystając z iTerm, byłem w stanie uzyskać powłokę, ustawiając komendę start na /bin/bash. W tej powłoce jednak sudonie działa. Wisi (bez wyświetlania monitu) oraz ctrl-Ci ctrl-Dwykonywać żadnej pracy, gdy wisi.

Używanie niektórych innych programów również nie działa w tej powłoce: nodelub /usr/local/bin/nodeoba się zawieszają. O ile mi wiadomo, są to programy /usr/local/bin.

Aktualizacja 2:

brew list --full-name wyniki w tych pakietach:

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

Aktualizacja 3:

Te punkty są zgodne z odpowiedzią @ Monomeeth:

1. Kiedy tak się dzieje, loginelement pojawia się na monitorze aktywności. (Force) Wyjście z niego powoduje także zamknięcie wiszącego okna terminalu. Ręczne zamknięcie okna nie powoduje loginodejścia procesu w Monitorze aktywności.

2. Tytuł terminala to Terminal — login — term big — ttys001 — 89x18 — ⌘1, gdzie term bigjest nazwa ustawień.

3. W sudomonitorze aktywności nie ma żadnego procesu. Mogę utworzyć sudoproces, otwierając iTerm.app (który używa bash) i uruchamiając go sudo echo ok. Nie może być Quit, ale Force Quit działa i zabija go:

   bash-3.2 $ sudo echo ok Zabity: 9

Aktualizacja 4:

Kiedy tak się dzieje, uruchamianie loginz powłoki, która jest nadal dostępna , działa, podczas gdy loginw nowszych powłokach wydaje się, że się zawiesił.

Aktualizacja 5:

Niedawno dostałem nowy laptop (MacBook Pro 2017, bez paska dotykowego) i problem nadal występuje.

Zmieniłem również powłoki: korzystam teraz fishz dość waniliowej konfiguracji. Myślę, że to wyklucza skorupę jako winowajcę.

System operacyjny został również zaktualizowany do wersji 10.13.3 (17D47) High Sierra.

Próbowałem zainstalować jak najmniej na tym komputerze:

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

Nie jestem pewien, co to może być teraz. Jedyne aplikacje, o których mogę myśleć, to Divvylub są Apptivateone przestarzałe. To jest skrzyżowanie tego, co zostało zainstalowane na starej i nowej maszynie:

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

Aktualizacja 6:

Oto zrzut ekranu:

Aktualizacja 7:

Moja env zwykle wygląda następująco:

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

Jak zapewne wiesz, rozwiązywanie problemów jest procesem eliminacji i często wymaga sporo cierpliwości. Chciałbym spróbować kilku rzeczy, aby dojść do sedna tego problemu.

1. Potwierdź, że zawiesza się podczas logowania

Jeśli proces, na którym się zawiesił, jest naprawdę podczas logowania , oznacza to, że proces nadal czeka na utworzenie sesji logowania. Zakładając, że tak jest, to nie próbowałby jeszcze uruchomić powłoki.

Aby to potwierdzić, następnym razem, gdy wystąpi ten problem, uruchom Monitor aktywności, aby sprawdzić, czy powłoka działa, czy widzisz tylko proces logowania .

Gdy będziesz miał okazję to zrobić, zgłoś to, co znalazłeś.

UWAGA: - Jeśli masz otwarte inne terminale, upewnij się, że sprawdzasz odpowiedni proces. Domyślam się, że proces zawieszania jest tym, który ma najwyższy numer identyfikatora procesu (PID).

2. Jaki jest tytuł terminalu?

Czy następnym razem, gdy pojawi się ten problem, możesz zanotować tytuł okna terminalu i zgłosić go z powrotem?

3. Zabij sudo

Oświadczasz, że ponowne uruchomienie MBP zawsze rozwiązuje ten problem.

Jednak następnym razem, gdy pojawi się ten problem (może po zrobieniu tego, co opisałem w punkcie 1 powyżej), chciałbym, abyś spróbował zabić sudo z Monitora aktywności.

Po wypróbowaniu tego, daj nam znać, co się stanie.

4. Spróbuj przenieść swoje pliki .bash *

Możliwe jest (z różnych powodów), że w katalogu użytkownika może być plik .bash_profile, co powoduje sporadyczne problemy. Jest to coś, czego możesz nawet nie być świadomy, ale możesz użyć Automatora do uruchomienia skryptu, który wyszukuje i przenosi dowolne pliki .bash.

Oto przykładowy skrypt do zrobienia tego:

cd ~

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

Ten skrypt przenosi wszystkie pliki zaczynające się od .bash w folderze domowym do nowo utworzonego przeniesionego podfolderu.

Po uruchomieniu skryptu sprawdź ten folder i daj nam znać, czy faktycznie masz w nim jakieś pliki.

UWAGA: - Nowy podfolder można oznaczyć dowolnie. Aby to zrobić, po prostu zmień dwa wystąpienia przeniesienia w skrypcie na dowolną etykietę, której chcesz użyć.

[AKTUALIZACJA]

Jeszcze kilka rzeczy do wypróbowania.

5. Spróbuj wyczyścić pliki * .asl

Jeśli jeszcze tego nie zrobiłeś, spróbuj wyczyścić pliki * .asl. Aby to zrobić, wykonaj następujące czynności:

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

UWAGA: - Może to zająć trochę czasu, ponieważ tworzy nową powłokę. Po zakończeniu upewnij się, że całkowicie zamknąłeś terminal, aby zmiany odniosły skutek.

6. Tryb awaryjny

Czy zauważasz jakąkolwiek różnicę w zachowaniu, gdy uruchamiasz MBP w trybie awaryjnym? Aby uruchomić w trybie awaryjnym:

1. Całkowicie zamknij komputer Mac
2. Uruchom ponownie komputer Mac
3. Natychmiast naciśnij Shiftklawisz i przytrzymaj go
4. Puść Shiftklucz, gdy zobaczysz okno logowania (UWAGA: Jeśli masz włączoną funkcję FileVault, może być konieczne dwukrotne zalogowanie).
5. Po uruchomieniu MBP spróbuj użyć Terminala i sprawdź, czy nadal możesz replikować problem?
6. Po zakończeniu możesz wyjść z trybu awaryjnego, uruchamiając ponownie MBP w normalny sposób

7. Otwórz katalog

Prawdopodobnie nie dotyczy to twojego przypadku, ponieważ nie wspominasz o tym, ale jeśli masz połączenie z siecią Open Directory, może to również powodować problemy. Zwykle wiązałoby się to z odczekaniem około 10–15 sekund, ale widziałem doniesienia o tym, że logowanie w terminalu zajmuje w tej sytuacji co najmniej pięć minut.

Wydaje się, że to idealne dopasowanie przekraczające maksymalną liczbę procesów na użytkownika (lub ewentualnie maksymalną liczbę procesów).

W standardowej instalacji macOS otrzymujesz 709 na użytkownika ( ulimit -u) i maksymalnie 1064 procesów ( sysctl -a | grep maxp)

Łatwym sposobem na ich zwiększenie jest zainstalowanie Server.app z App Store, a następnie ponowne uruchomienie. Możesz także ustawić tryb wydajności dla wyższych limitów.

Ponieważ nie opisałeś swojej konfiguracji (wersja i kompilacja systemu operacyjnego), oto kilka wskazówek - koniecznie sprawdź SIP ograniczający możliwość zmiany plików, jeśli czytasz niektóre starsze artykuły na temat zmiany limitów bez konieczności instalowania serwera. aplikacja:

• Jak zwiększyć „ulimit -u” (maksymalna liczba procesów użytkownika)?
• http://blog.dekstroza.io/ulimit-shenanigans-on-osx-el-capitan/
• https://support.apple.com/en-us/HT3854
• https://support.apple.com/en-us/HT4022
• /server/15564/where-are-the-default-ulimits-specified-on-os-x-10-5

Widzę to również od kilku miesięcy. Niezwykle frustrujące. Jedyną rzeczą, która to naprawia, jest restart.

• MBP z połowy 2015 r. (Bez paska dotykowego)
• MacOS 10.12.6 beta

Czasami zawiesza się logowanie po interakcji z tmux.

Bezskutecznie wypróbowałem wszystkie zalecane podejścia.

Nie jestem pewien, czy jest to powiązane, ale lsof -p LOGIN_PIDpokazuje dość masywny plik /private/var/db/dyld/dyld_shared_cache_x86_64hdo zawieszonego procesu logowania.

Aktualizacja 29.08.2017:

Nadal mam problem. Czasami, gdy komputer znajduje się w złym stanie, mam otwarte okna terminala, które są już pomyślnie zalogowane i mogę użyć go do debugowania.

Wiele poleceń nie działa poprawnie, ale wszystkie mają problem z pisaniem (myślę, że na standardowe wyjście). Na przykład, kiedy biegam ls -al, widzę ls: write erroremitowane do stderr. Kiedy biegam ls -al > /dev/null, nic nie jest drukowane do stderr.

Ważne jest, aby traktować prawdziwy problem, a nie tylko objaw. Wypróbuj poniższe sugestie i zaktualizuj je, aby na ich podstawie zasugerować także dalsze środki zaradcze.

1. Który użytkownik jest właścicielem terminala? :
   Moje pierwsze przeczucie polega na tym, że może to mieć związek z konfiguracją konta. Jeśli terminal próbuje uzyskać dostęp do zasobów lub katalogów, które może uzyskać tylko użytkownik admin (jeśli twoje konto nie jest administratorem), może to prowadzić do stanu zawieszenia - uniemożliwiając dostęp do terminala. Więc śmiało i upewnij się, że kiedy zaczynasz sesję terminalową, jest ona lokalna dla twojego użytkownika, a nie innego użytkownika. Fakt, że nie możesz stworzyć procesu sudo, wskazuje mi ten kierunek.

2. Wpisz Control-Z lub Command-Z:
   Ta sekwencja klawiszy sterujących zawiesza uruchomiony program i wyświetla monit powłoki. Teraz możesz wpisać polecenie zadania, aby znaleźć nazwę programu, a następnie ponownie uruchomić program za pomocą fg lub zakończyć go za pomocą kill.

3. Naciśnij Command-C :
   To przerwie, jeśli terminal próbuje uruchomić program w tle. Spróbuj kilka razy. Uwaga, jeśli zobaczysz jakieś dane wyjściowe

4. Wpisz Control-Q :
   Jeśli wyjście zostało zatrzymane za pomocą Control-S, spowoduje to ponowne uruchomienie.

5. Zdobądź alternatywną powłokę :
   jeśli chcesz wypróbować inną powłokę na kilka dni, ich zachowania mogą czasem pomóc ci zrozumieć problem z terminalem, jeśli działają one w określony sposób. Sprawdź poniższe linki, aby znaleźć alternatywy

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

Pomoże poznać następujące, o ile jeszcze nie wspomniano:

• Jak inicjujesz sesję terminalową? Czy dzieje się tak dzięki wyróżnieniu, ikonie na pulpicie czy w inny sposób?

• Co robi terminal, gdy się zawiesza? Czy jest w trakcie wykonywania polecenia (to samo polecenie za każdym razem, zanim się zawiesi), czy po prostu zawiesza się od momentu rozpoczęcia sesji terminalu / systemu Windows.

• Do czego zwykle używasz swojego terminala? Jeśli większość twoich zastosowań dotyczy tylko poleceń związanych z git, sugerowałbym użycie czegoś takiego jak Github dla komputerów Mac, ponieważ zwykle możesz zrobić większość rzeczy stamtąd.

Chciałbym spróbować wyłączyć logowanie SIP i dtrace, aby znaleźć główną przyczynę (Aby wyłączyć i ponownie włączyć SIP, zobacz 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

Próbując podać przykładowy wynik, właśnie odkryłem, że rzeczy są znacznie prostsze, niż myślałem. Nie trzeba wyłączać SIP, wystarczy skopiować login.

dtuss zwróci wywołania systemowe i może podpowiedzieć, gdzie coś pójdzie nie tak.

cp /usr/bin/login .
sudo ls

podaj swoje hasło Więc zrób

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

wprowadź swoją nazwę użytkownika, naciśnij enter

wprowadź hasło, naciśnij enter

wpisz „exit”, naciśnij enter

i w końcu przesłać plik dtruss_login.txt na np. https://gist.github.com/

Możesz skopiować zawartość pliku do schowka w ten sposób

cat dtruss_login.txt | pbcopy

Przykładowy login można znaleźć tutaj: https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

Druga liczba całkowita w każdej linii to czas połączenia.

Oczywiście, byłoby wspaniale, gdybyś mógł uruchomić to, gdy logowanie się zawiesza, ale jeśli dobrze zrozumiem, jest to niemożliwe ... może ty lub ktoś inny ma pomysł, jak „dtruss login”, gdy terminal się zawiesza ?

loginKod źródłowy polecenie zostało opublikowane przez firmę Apple. Witryna jest źródłem macOS 10.13.3 . Wymagane jest tylko pobranie system_cmds-790.30.1. Po pobraniu projekt można łatwo zmodyfikować, aby budował tylko loginpolecenie. Zmodyfikowany projekt i loginpolecenie zostały umieszczone w GitHub pod adresem davidanderson61 / system_cmds-10.13.3 .

Chodzi o to, aby zmodyfikować, loginaby zapisać informacje debugowania w konsoli. Pomoże to ustalić, dlaczego loginpolecenie się zawiesza. Modyfikacje mogą być wprowadzone przez każdego, kto chce wziąć udział. Zakładałem, że to byłbym ja.

Zainstaluj loginpolecenie debugowania .

1. Wybierz najnowszą wersję ze strony davidanderson61 / system_cmds-10.13.3 / releases .

2. Pobierz loginpolecenie debugowania do swojego Downloadsfolderu. W sekcji „Zasoby” kliknij prawym przyciskiem myszy logini wybierz „Pobierz połączony plik jako”, a następnie wybierz „Zapisz”.

3. Częściowo wyłącz ochronę integralności systemu (SIP). Polecenie podano poniżej. Przed wprowadzeniem polecenia należy uruchomić system MacOS Recover , a następnie okno Terminal.

   csrutil  enable  --without  fs

4. Wpisz polecenie podane poniżej, aby zapisać oryginalne loginpolecenie. Jeśli login.orignaljuż istnieje, możesz pominąć ten krok.

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

5. Wprowadź polecenia podane poniżej, aby skopiować loginpolecenie debugowania i ustawić odpowiednie uprawnienia.

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

6. Włącz ochronę integralności systemu (SIP). Wpisz następujące polecenie. Następnie powinieneś zrestartować.

   sudo  csrutil  clear

Skonfiguruj aplikację konsoli

Poniżej znajdują się kroki, aby skonfigurować aplikację konsoli tak, aby wyświetlała tylko komunikaty z loginpolecenia.

1. Otwórz aplikację konsoli.

2. Dodaj PIDkolumnę, jak pokazano poniżej.

   

3. Wpisz loginw polu wyszukiwania.

   

   Gdy pole wyszukiwania jest aktywne, naciśnij returnklawisz. Pole wyszukiwania powinno zmienić się na pokazane poniżej.

   

4. Zmień Anyna Process, jak pokazano poniżej.

   

5. Lista Zmień Containsna Equals, jak pokazano poniżej.

   

6. Wybierz Saveprzycisk. Po wyświetleniu monitu „Zapisz wyszukiwanie jako:” wpisz Login, a następnie wybierz Save.

   

Wyniki powinny wyglądać jak pokazano poniżej. Następnym razem, gdy otworzysz aplikację Console, będziesz musiał jedynie wybrać przycisk „Zaloguj się”.

dodatek

Jak powstało repozytorium GitHub.

1. Kliknij system_cmds.xcodeprojplik otwarty w Xcode.
2. Z paska menu wybierz Source Control->Create Git Repositories....
3. Z paska menu wybierz Product->Scheme->New Scheme.... Następnie wybierz loginjako cel i nazwę.
4. Z paska menu wybierz Project->Build.
5. Zamknij Xcode.
6. Zaloguj się na GitHub i utwórz nowe repozytorium.
7. U góry strony Szybkiej instalacji repozytorium GitHub kliknij, aby skopiować adres URL zdalnego repozytorium.

8. W oknie aplikacji Terminal wprowadź następujące polecenie. Zamień na <remote repository URL>adres URL skopiowany w poprzednim kroku.

   git  remote  add  origin  <remote repository URL>

9. Otwórz projekt w Xcode i na pasku menu wybierz Source Control->Push....

Jak powstało pierwsze wydanie

1. W oknie aplikacji Terminal wprowadź następujące polecenia.

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

2. Skopiuj wbudowane loginpolecenie do swojego Downloadsfolderu.

3. Na swoim koncie GitHub utwórz nową wersję jako v1.0. Dołącz ~/Downloads/loginjako plik binarny.

Miałem ten problem również podczas uruchamiania konsoli SBT w emacsie. Ilekroć wychodziłem z konsoli sbt, po prostu zabijając okno, zamiast wyjść „ładnie” z konsoli sbt, powodowało to zawieszenie się procesu Java nawet po zamknięciu okna i w jakiś sposób uniemożliwiało utworzenie nowych sesji terminala. Wymusiłem zabicie procesu Java z monitora aktywności, a terminal wiszący faktycznie się rozpoczął, zarówno z poziomu emacsa, jak i nowej karty.

Teraz po prostu upewniam się, że dobrze zamknąłem komendę exitlub ctrl-d(lub ctrl-c ctrl-dw emacsie term/multi-term), a następnie zabiłem okno.

1. Sprawdź, czy proces naprawdę zawiesza się podczas login
2. Zajrzyj do Monitora aktywności i uważaj na rootprocesy (np. Nano, emacs, vim), które mogłeś zainicjować i nie rzucić poprawnie (awaria, właśnie zabiłeś terminal itp.), Które nadal działają.
3. Zabij ten proces (y), a logowanie powinno działać natychmiast.

Tylko moje dwa centy.

Zainstalowałem pakiet Terminus dla Sublime Text, który pozwala mi uruchamiać terminal w moim edytorze tekstu.

Zamknięcie Sublime Text natychmiast pozwoliło mojemu terminalowi znów zacząć działać.

FWIW, miałem ten sam problem. Rozwiązałoby się to po ponownym uruchomieniu, ale chciałem zaoszczędzić czas na robieniu tego wiele razy dziennie. Zaczęło się po użyciu określonego środowiska nodeJS, więc przeszedłem do monitora aktywności i zauważyłem, że proces węzła jest w toku. Zabicie tego wystąpienia rozwiązało problem dla mnie, więc jeśli ktoś, kto tego doświadczył, niedawno zaczął pracować lokalnie z węzłem lub npm, może to być twój problem.

Zabicie zabłąkanej instancji nvim naprawiło to dla mnie. Zakładam, że nie jest to specyficzne dla nvim, ale coś, co robił nvim w moim przypadku, powodowało problemy. Szukałbym nieoczekiwanej osieroconej aplikacji terminalu w monitorze aktywności i zabiłbym ją, jeśli ją znajdziesz.