Terminalanmeldung hängt

Ich habe ein seltsames Problem auf meinem neuen MacBook Pro (Ende 2016, Touch Bar).

Es funktioniert gut und dann, nachdem es eine Weile benutzt wurde, funktioniert das Öffnen neuer Terminalfenster nicht, weil es loginhängt. Neustart behebt das Problem.

Dies scheint ein Problem zu sein, das einige andere Leute hatten, also habe ich bereits alle ihre Lösungen ausprobiert (von1 und [2] ):

  1. Entfernen~/Library/Preferences/com.apple.Terminal.plist
  2. Festlegen meiner Standard-Shell auf eine andere Shell (von /bin/zshbis /bin/shoder /bin/bash)
  3. Entfernen oder Bereinigen von my .profile, .zprofile, ... Dies funktioniert nicht und ich kann validieren, dass das Problem auftritt, bevor die Shell überhaupt aufgerufen wird, denn wenn ich echo HEYals erste Zeile meiner .zshenvthis nicht einmal erreicht werde. Es muss logindie Probleme verursachen. Das Bearbeiten /etc/profilezum Hinzufügen eines Echos oben zeigt ebenfalls nichts an
  4. Das Ändern der Run command:Einstellung in meiner Terminalkonfiguration in etwas wie echo foofunktioniert auch nicht (es Run inside shellaktiviert oder deaktiviert zu lassen, ändert nichts).

Weitere Hinweise:

  • Wie [2] werden ssh-add -KSchlüssel zwischen Neustarts nicht beibehalten, etwas, mit dem ich vorher nie Probleme hatte.
  • Die Konsole zeigt keine verdächtigen Fehler oder Warnungen an.
  • Das Öffnen eines neuen TerminalFensters scheint eine tty-Datei ( /dev/ttys<number>) zu erstellen.
  • In diesem Fall spielt es keine Rolle, ob ich Terminal.app oder iTerm.app verwende
  • Ich habe eine ziemlich saubere Installation (habe gerade meinen Laptop bekommen, keine Backups wiederhergestellt, nur einige Apps mit brew installund installiert brew cask install).

Das ist wirklich schwer zu debuggen, weil ich es nicht reproduzieren kann und oft kann ich nicht einmal ein neues Terminal öffnen, um herauszufinden, was los ist.

Hat jemand Tipps?

Aktualisieren:

Mit iTerm konnte ich eine Shell abrufen, indem ich den Startbefehl auf /bin/bash. In dieser Shell sudofunktioniert das allerdings nicht. Es hängt (ohne die Eingabeaufforderung anzuzeigen) und ctrl-Cfunktioniert ctrl-Dnicht, wenn es hängt.

Die Verwendung einiger anderer Programme funktioniert in dieser Shell auch nicht: nodeoder /usr/local/bin/nodebeide hängen. Soweit ich das beurteilen kann, sind es Programme, die in /usr/local/bin.

Aktualisierung 2:

brew list --full-nameErgebnisse in diesen Paketen:

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

Aktualisierung 3:

Diese Punkte stimmen mit der Antwort von @Monomeeth überein:

  1. Wenn es passiert, wird ein loginElement im Aktivitätsmonitor angezeigt. (Force) Beim Beenden wird auch das hängende Terminalfenster geschlossen. Durch manuelles Schließen des Fensters verschwindet der loginVorgang nicht im Aktivitätsmonitor.

  2. Der Titel des Terminals ist Terminal — login — term big — ttys001 — 89x18 — ⌘1, wobei term bigder Name der Einstellungen ist.

  3. In der Aktivitätsanzeige wird kein sudoProzess angezeigt. Ich kann einen sudoProzess erstellen, indem ich iTerm.app (das Bash verwendet) öffne und sudo echo okdort ausführe. Es kann nicht beendet werden, aber Force Quit funktioniert und beendet es:

    bash-3.2$ sudo echo ok Getötet: 9

Aktualisierung 4:

Wenn es passiert, funktioniert das Ausführen vonlogin einer Shell, die noch verfügbar ist , während die in neueren Shells zu hängen scheint.login

Aktualisierung 5:

Ich habe kürzlich einen neuen Laptop (MacBook Pro 2017, keine Touch Bar) und das Problem besteht weiterhin.

Ich habe auch die Shells gewechselt: Ich verwende jetzt fisheine hübsche Vanilla-Konfiguration. Ich denke, das schließt die Muschel als Schuldigen aus.

Das Betriebssystem wurde ebenfalls auf 10.13.3 (17D47) High Sierra aktualisiert.

Ich habe versucht, so wenig wie möglich auf dieser Maschine zu installieren:

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

Keine Ahnung was das jetzt sein kann. Die einzigen Apps, die mir einfallen, sind Divvyoder Apptivateda beide veraltet erscheinen. Dies ist die Schnittmenge dessen, was auf der alten vs. der neuen Maschine installiert wurde:

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

Aktualisierung 6:

Außerdem hier ein Screenshot:Bildschirmfoto

Aktualisierung 7:

Meine Env sieht normalerweise so aus:

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
Dies könnte ein lahmer Vorschlag sein, aber haben Sie versucht, den Apple-Kundendienst zu kontaktieren? Ihre Frage hat nicht viel Beachtung gefunden, seit Sie sie gepostet haben, und die Support-Mitarbeiter haben möglicherweise von diesem Problem gehört. Mein einziger anderer Vorschlag wäre, MacOS neu zu installieren. Da Ihr Mac jedoch so neu ist, weiß ich nicht, ob dies funktionieren würde.
@klanomath fertig!
Um herauszufinden, was die Anmeldung tut, wählen Sie sie im Aktivitätsmonitor aus und wählen Sie Beispielprozess. Dasselbe gilt für andere hängende Prozesse. Diese Debugging-Ebene ist jedoch möglicherweise nicht für StackExchange Q&A geeignet. Es kann besser sein, entweder einen Fehlerbericht mit der Beispieldatei bei Apple einzureichen oder jemanden zu finden, der Unterstützung bei der Diagnose des Problems auf dieser Ebene anbieten kann. Siehe developer.apple.com/bug-reporting
Wie lange hängt es? Haben Sie versucht, es zehn Minuten lang laufen zu lassen? Ist Ihr Computer an ein Open Directory-Netzwerk gebunden? Insbesondere muss die Anmeldung Ihre Benutzerinformationen abrufen, und wenn Sie sich in einem OD-Netzwerk mit einem ausgelasteten/nicht reagierenden Verzeichnisserver befinden, kann es einige Minuten dauern, bis er antwortet. andere Programme rufen ebenfalls Benutzerinformationen ab und könnten unter diesem Problem leiden.
Ich habe nicht versucht, länger zu warten, werde es beim nächsten Mal versuchen. Ich bin nicht an ein Open Directory-Netzwerk gebunden, diese Fehler treten auch auf, wenn ich mich in keinem Netzwerk befinde.
Habe immer noch dieses Problem. Auch auf meinem neuen MacBook 2017 ohne Touch Bar. Ich habe fast nichts installiert und verwende eine andere Shell ( fishmit einer hübschen Vanilla-Konfiguration), sodass ich wirklich nicht sagen kann, was es ist.
Wenn Sie glauben, dass das Problem beim Login-Befehl liegt, wären Sie dann bereit, einen Login-Befehl zu verwenden, der Debug-Meldungen in die Konsole schreibt? Mit anderen Worten, nehmen Sie den Quellcode des Anmeldebefehls, fügen Sie Debugging-Code hinzu, kompilieren und verknüpfen Sie ihn und ersetzen Sie dann Ihren Anmeldebefehl durch den neuen.
Ich bin auch davon betroffen (und es kommt immer öfter vor...)
Übrigens: Das Schließen meiner Sitzung behebt das Problem nicht, nur ein Neustart tut es.
Ich habe neulich jemandem bei einem Problem geholfen, das diesem sehr ähnlich (vielleicht identisch) aussah. Ein paar Datenpunkte aus dieser Debug-Sitzung, falls es für jemanden nützlich ist (keine Ahnung, ob das auf Sie zutrifft, wenn Sie das bekommen, aber es ist, was ich gesehen habe): (1) Es schien, als wäre mit Pseudo-Terminals im Allgemeinen etwas seltsam -- insbesondere ist mir aufgefallen, dass ps -efeine Reihe von Prozessen gedruckt werden, aber nur solche ohne zugewiesenes Terminal; cd /dev; echo tty*funktionierte, ls -l tty*würde aber hängen... ls -l ttys?funktionierte, ls -l ttys???würde hängen.
(2) Es gab einige hängende sudoProzesse in der Liste der nicht mit dem Terminal verbundenen Prozesse ( ??in der psAusgabe) und nodewurden verwendet. Ich erwähne dies, weil ich sowohl nodeals auch sudoin der Frage sehe. Ich bin mir nicht sicher, ob dies etwas Relevantes oder nur Zufall ist, aber ich dachte, ich erwähne es.
Oh ja, und das folgt irgendwie aus Punkt (1) oben, aber nur als zusätzlicher Datenpunkt: ps -fp $$von einer ansonsten funktionierenden Shell reagierte auch nicht. Ich habe es nicht mit einem benutzerdefinierten Format psversucht, aber es ttykönnte interessant sein, einen zu versuchen, der das Feld ausschließt. Oh, und der Neustart hat (zumindest vorübergehend) das Problem auf dem Computer behoben, auf dem ich das gesehen habe. :-/

Antworten (12)

Wie Sie sicher wissen, ist die Fehlersuche ein Eliminierungsprozess und erfordert oft einiges an Geduld. Ich möchte ein paar Dinge ausprobieren, um der Sache für Sie auf den Grund zu gehen.

1. Bestätigen Sie, dass es während der Anmeldung hängt

Wenn sich der Prozess, an dem er hängt, wirklich während der Anmeldung befindet, bedeutet dies, dass der Prozess immer noch darauf wartet, eine Anmeldesitzung zu erstellen. Angenommen, dies ist der Fall, dann hätte es noch nicht versucht, die Shell zu starten.

Um dies zu bestätigen, starten Sie beim nächsten Auftreten dieses Problems den Aktivitätsmonitor, um zu überprüfen, ob die Shell ausgeführt wird oder ob Sie nur einen Anmeldevorgang sehen .

Sobald Sie die Gelegenheit hatten, dies zu tun, melden Sie sich mit dem, was Sie gefunden haben.

HINWEIS:- Wenn Sie zufällig andere Terminals geöffnet haben, stellen Sie sicher, dass Sie den entsprechenden Prozess überprüfen. Ich vermute, dass der hängende Prozess derjenige mit der höchsten Prozess-ID-Nummer (PID) ist.

2. Was ist der Titel des Terminals?

Wenn dieses Problem das nächste Mal auftritt, können Sie sich den Titel des Terminalfensters notieren und berichten?

3. Beenden Sie sudo

Sie geben an, dass ein Neustart Ihres MBP dieses Problem immer löst.

Wenn Sie dieses Problem jedoch das nächste Mal haben (vielleicht nachdem Sie das getan haben, was ich oben unter 1 beschrieben habe), möchte ich, dass Sie versuchen, sudo von Activity Monitor zu beenden.

Wenn Sie dies versucht haben, lassen Sie uns wissen, was passiert.

4. Versuchen Sie, Ihre .bash*-Dateien zu verschieben

Es ist möglich (aus verschiedenen Gründen), dass Sie eine .bash_profile-Datei in Ihrem Benutzerverzeichnis haben und dies zeitweise Probleme verursacht. Dies ist etwas, dessen Sie sich vielleicht nicht einmal bewusst sind, aber Sie können Automator verwenden, um ein Skript auszuführen, das alle .bash-Dateien findet und verschiebt.

Hier ist ein Beispielskript dafür:

cd ~

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

Dieses Skript verschiebt alle Dateien, die mit .bash beginnen, in Ihrem Home-Ordner in einen neu erstellten verschobenen Unterordner.

Nachdem Sie das Skript ausgeführt haben, überprüfen Sie diesen Ordner und teilen Sie uns mit, ob Sie tatsächlich Dateien darin haben.

HINWEIS:- Sie können den neuen Unterordner beliebig benennen. Ändern Sie dazu einfach die beiden Vorkommen von moved im Skript in die gewünschte Bezeichnung.

[AKTUALISIEREN]

Einige weitere Dinge zum Ausprobieren.

5. Versuchen Sie, die *.asl-Dateien zu löschen

Falls noch nicht geschehen, versuchen Sie, die *.asl-Dateien zu löschen. Verwenden Sie dazu Folgendes:

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

HINWEIS:- Dies kann einige Zeit dauern, da eine neue Shell erstellt wird. Wenn Sie fertig sind, stellen Sie sicher, dass Sie das Terminal vollständig verlassen, damit die Änderungen wirksam werden.

6. Abgesicherter Modus

Bemerken Sie einen Unterschied im Verhalten, wenn Sie Ihr MBP im abgesicherten Modus starten? So booten Sie in den abgesicherten Modus:

  1. Fahren Sie Ihren Mac vollständig herunter
  2. Starten Sie Ihren Mac neu
  3. Drücken Sie sofort die ShiftTaste und halten Sie sie gedrückt
  4. Lassen Sie die ShiftTaste los, wenn Sie das Anmeldefenster sehen (HINWEIS: Wenn Sie FileVault aktiviert haben, müssen Sie sich möglicherweise zweimal anmelden).
  5. Sobald Ihr MBP gestartet ist, versuchen Sie es mit Terminal und sehen Sie, ob Sie das Problem immer noch replizieren können.
  6. Wenn Sie fertig sind, können Sie den abgesicherten Modus verlassen, indem Sie Ihr MBP wie gewohnt neu starten

7. Öffnen Sie das Verzeichnis

Dies trifft in Ihrem Fall wahrscheinlich nicht zu, da Sie es nicht erwähnen, aber wenn Sie mit einem Open Directory-Netzwerk verbunden sind, könnte dies auch Probleme verursachen. Normalerweise würde dies nur eine Wartezeit von etwa 10 bis 15 Sekunden bedeuten, aber ich habe Berichte von Terminal-Logins gesehen, die in dieser Situation fünf oder mehr Minuten dauern.

Vielen Dank! Ich verwende zsh, und selbst bei einem leeren .zshrc, .zprofile, .profile, usw. kommt die ID nicht vor, und das erklärt nicht, warum andere Programme /usr/local/binebenfalls hängen, also denke ich, dass 4. nicht im Bilde ist. Ich werde mit der Antwort auf die anderen Fragen zurückkommen, sobald ich sie bekommen habe.
Ein Update mit den Antworten auf diese Fragen hinzugefügt. loginscheint der Schuldige zu sein, erklärt aber immer noch nicht, warum es in iTerm mit bash.
Ich habe meine Antwort aktualisiert. Mir ist jedoch gerade aufgefallen, dass Sie nicht angegeben haben, wie lange Sie versucht haben, auf den Abschluss der Terminal-Anmeldung zu warten? Es wäre gut zu wissen, ob es sich irgendwann anmeldet oder ob es nur auf unbestimmte Zeit hängt.
@romeovs Ich frage mich nur, haben Sie dieses Problem jemals gelöst?
nein :( Ich arbeite noch daran. Es hat jedoch begonnen, viel seltener vorzukommen.
Vielen Dank für das Hinzufügen vieler präziser Vorschläge. Ich hatte das gleiche Problem und ein Neustart meines Mac hat bei mir funktioniert :)
FWIW, nvim wurde unordentlich beendet und lief immer noch im Hintergrund. Meine Punktdateien wurden auch mit OneDrive synchronisiert. Durch das Beenden des nvim-Prozesses konnte ich mich wieder anmelden. 🤷‍♂️

Dies scheint eine perfekte Lösung für Sie zu sein, wenn Sie die maximalen Prozesse pro Benutzer (oder möglicherweise maximale Prozesse) überschreiten.

Bei einer standardmäßigen macOS-Installation erhalten Sie 709 pro Benutzer ( ulimit -u) und maximal 1064 Prozesse ( sysctl -a | grep maxp)

Eine einfache Möglichkeit, diese zu erhöhen, besteht darin, Server.app aus dem App Store zu installieren und dann neu zu starten. Sie können den Leistungsmodus auch für höhere Limits einstellen.

Da Sie Ihr Setup (OS-Version und Build) nicht beschrieben haben, hier einige Tipps – überprüfen Sie unbedingt, ob SIP Ihre Fähigkeit zum Ändern von Dateien einschränkt, wenn Sie einige der älteren Artikel zum Ändern der Limits lesen, ohne auf die Installation des Servers zurückzugreifen. Anwendung:

Ausgezeichneter Punkt! Das hatte ich gar nicht bedacht. :)
@Monomeeth deine Antwort ist großartig. Viele tolle Sachen drin.
@bmike Gibt es eine Möglichkeit, die Gesamtzahl der Prozesse zu überprüfen, um zu überprüfen, ob dies der Fall ist? Vielleicht kann ich es sogar reproduzieren, indem ich dann 709-Prozesse erstelle?
Basierend auf einem Fall, den ich von etwas gesehen habe , das das gleiche Problem zu sein scheint , glaube ich nicht, dass dies der Fall ist. Das Starten neuer Prozesse (von einer vorhandenen Shell) würde gut funktionieren ... aber das Abgleichen von Dateien stat(über ) würde (anscheinend) hängen bleiben ... Natürlich kann es mehrere Ursachen für ähnliche Symptome geben, daher kann dies immer noch nützlich sein Antwort, dachte nur, ich würde darauf hinweisen, was ich gesehen habe. ls -l/dev/ttys???

Das beobachte ich auch seit einigen Monaten. Extrem frustrierend. Das einzige, was es behebt, ist ein Neustart.

  • Mitte 2015 MBP (keine Touchbar)
  • MacOS 10.12.6 Beta

Manchmal kommt es nach der Interaktion mit tmux zum Hängen der Anmeldung.

Ich habe alle empfohlenen Ansätze erfolglos ausprobiert.

Nicht sicher, ob es damit zusammenhängt, aber a lsof -p LOGIN_PIDzeigt eine ziemlich umfangreiche Datei /private/var/db/dyld/dyld_shared_cache_x86_64hfür den hängenden Anmeldeprozess.

Aktualisierung vom 29.08.2017:

Habe das Problem immer noch. Manchmal, wenn der Computer in einen schlechten Zustand gerät, habe ich offene Terminalfenster, die bereits erfolgreich angemeldet sind und die ich zum Debuggen verwenden kann.

Viele Befehle werden nicht richtig ausgeführt, aber sie alle zeigen ein Muster von Schreibproblemen (zu stdout, denke ich). Wenn ich beispielsweise laufe ls -al, sehe ich , dass ls: write errores an stderr ausgegeben wird. Wenn ich laufe ls -al > /dev/null, wird nichts auf stderr gedruckt.

Hattest du Glück, das herauszufinden?
Das Problem ist für mich behoben, seit ich mein Betriebssystem aktualisiert habe. Es wurde für einige Nebenversionen behoben, und ich verwende derzeit 10.13.3 (17D47).
Ich verwende auch 10.13.3 (17D47)! Es ist seltener geworden, tritt aber manchmal immer noch auf.

Es ist wichtig, das eigentliche Problem zu behandeln und nicht nur das Symptom. Probieren Sie also die folgenden Vorschläge aus und aktualisieren Sie sie, sodass auf dieser Grundlage auch weitere Abhilfemaßnahmen vorgeschlagen werden können.

  1. Welchem ​​Benutzer gehört das Terminal? :
    Meine erste Vermutung ist, dass dies mit der Einrichtung Ihres Kontos zusammenhängen kann. Wenn das Terminal versucht, auf die Ressourcen oder Verzeichnisse zuzugreifen, auf die nur der Administrator zugreifen kann (wenn Ihr Konto kein Administrator ist), kann dies zum Einfrieren des Zustands führen, sodass Sie nicht auf das Terminal zugreifen können. Machen Sie also weiter und stellen Sie sicher, dass beim Starten einer Terminalsitzung diese lokal für Ihren Benutzer und nicht für einen anderen Benutzer ist. Die Tatsache, dass Sie keinen Sudo-Prozess erstellen können, weist mich in diese Richtung.

  2. Geben Sie Control-Z oder Command-Z ein:
    Diese Steuertastenfolge hält ein Programm an, das möglicherweise ausgeführt wird, und gibt Ihnen einen Shell-Prompt. Jetzt können Sie den Befehl jobs eingeben, um den Namen des Programms zu finden, und dann das Programm mit fg neu starten oder mit kill beenden.

  3. Drücken Sie Command-C :
    Dies wird unterbrochen, wenn das Terminal versucht, ein Programm im Hintergrund auszuführen. Versuchen Sie es ein paar Mal. Beachten Sie, ob Sie eine Ausgabe sehen

  4. Geben Sie Control-Q ein :
    Wenn die Ausgabe mit Control-S gestoppt wurde, wird sie dadurch neu gestartet.

  5. Holen Sie sich eine alternative Shell :
    Wenn Sie für ein paar Tage eine andere Shell ausprobieren möchten, kann Ihnen deren Verhalten manchmal helfen, das Problem mit Terminal zu verstehen, wenn sie sich auf eine bestimmte Weise verhalten. Überprüfen Sie diese Links unten auf Alternativen

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

Hilft, Folgendes zu wissen, falls noch nicht erwähnt:

  • Wie initiieren Sie die Terminalsitzung? Ist dies über Spotlight oder ein Desktop-Symbol oder auf andere Weise?

  • Was macht das Terminal, wenn es hängt? Ist es mitten in der Ausführung eines Befehls (immer derselbe Befehl, bevor es hängt) oder hängt es nur ab dem Moment, an dem Sie eine Terminalsitzung / Windows starten.

  • Wofür verwenden Sie Ihr Terminal normalerweise? Wenn ein Großteil Ihrer Verwendung nur für git-bezogene Befehle verwendet wird, würde ich vorschlagen, so etwas wie Github für Mac zu verwenden, da Sie normalerweise die meisten Dinge von dort aus erledigen können.

^ZStrg-Z und Strg-C werden beide nur als und auf dem Bildschirm angezeigt ^C, Strg-Q macht nichts. Normalerweise öffne ich die Shell mit Command-N im Terminal. Ich bin ein Vollzeit-Programmierer, also benutze ich das Terminal im Grunde für alles. Das Terminal hängt, bevor irgendetwas ausgeführt wird (on login).
@romeovs Was ist mit Zeiger 1, was ist Ihr Benutzertyp? Ein Screenshot mit dem Problem würde auch helfen. Vielen Dank
Ich bin der Standardbenutzer und -administrator auf meinem MacBook.

Ich würde versuchen, die SIP- und dtrace-Anmeldung zu deaktivieren, um die Ursache zu finden (um SIP zu deaktivieren und wieder zu aktivieren, siehe 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

Beim Versuch, Ihnen eine Beispielausgabe zu geben, habe ich gerade herausgefunden, dass die Dinge viel einfacher sind, als ich dachte. Sie müssen SIP nicht deaktivieren, kopieren Sie einfach die Anmeldung.

dtuss gibt die Systemaufrufe zurück und gibt möglicherweise einen Hinweis darauf, wo etwas schief geht.

cp /usr/bin/login .
sudo ls

geben Sie Ihr Passwort ein. Dann mach

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

Geben Sie Ihren Benutzernamen ein und drücken Sie die Eingabetaste

Geben Sie Ihr Passwort ein und drücken Sie die Eingabetaste

Geben Sie „exit“ ein und drücken Sie die Eingabetaste

und schließlich dtruss_login.txt auf zB https://gist.github.com/ hochladen

Sie können den Inhalt der Datei so in die Zwischenablage kopieren

cat dtruss_login.txt | pbcopy

Einen Beispiel-Login finden Sie hier: https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

Die zweite ganze Zahl in jeder Zeile ist die Zeit, die der Anruf gedauert hat.

Natürlich wäre es großartig, wenn Sie dies ausführen könnten, wenn das Login hängt, aber wenn ich Sie richtig verstehe, ist dies unmöglich .... vielleicht haben Sie oder jemand anderes eine Idee, wie man sich 'dtruss login', wenn das Terminal hängt ?

Autsch. Dies scheint eine Menge Schmerz für etwas zu sein, das Stunden oder Tage nach dem Start der Anmeldung passiert. Können Sie eingrenzen, was dtrusserfasst und angezeigt werden könnte?
Wenn die Anmeldung in einem Systemaufruf hängt, was sehr wahrscheinlich ist, wird es Ihnen angezeigt. Wenn es zwischen Systemaufrufen hängt, zeigt es Ihnen, zwischen welchen, und gibt Ihnen einen Hinweis darauf, was tatsächlich vor sich geht. zB wenn es hängt, nachdem es eine bestimmte Konfigurationsdatei durch einen Systemaufruf gelesen hat, tritt der Fehler höchstwahrscheinlich während des Analysierens dieser Konfiguration auf. Da muss man genau hinsehen. Könnte auch netzwerkbezogen sein ... wer weiß, bis Sie es debuggen;)
Das Problem ist, dass ich das Problem nicht manuell reproduzieren kann, bis es zu spät ist.
Führen Sie dann den Befehl in einer Schleife "für immer" aus und machen Sie ">> dtruss_login.txt 2>&1" anstelle von "2> dtruss_login.txt". Sobald der Fehler auftritt, sehen Sie in am Ende der Ausgabe.
Ich konnte endlich ein dtruss-Protokoll abrufen: gist.github.com/romeovs/6661ae0db77e57281b531676cc5dc007 Da die Anmeldung hängt, wird dies nie beendet, also habe ich nach etwa 10 Sekunden Strg-C gedrückt.
Sie haben nicht einmal Ihren Benutzernamen eingegeben ... Sie meinen also, Sie erhalten nicht einmal eine Anmeldeaufforderung? Denn bis zu diesem Punkt sieht im dtruss alles ganz normal aus ... es sieht so aus, als hätten Sie gerade Strg-C gedrückt, als Sie Ihren Benutzernamen eingeben sollten.
@ user2707001 Aber ich muss nie meinen Benutzernamen eingeben, das ist Terminal.app?
Was meinst du damit, dass du deinen Benutzernamen nie eingeben musst? Wenn Sie "login" in "Terminal.App" schreiben, heißt es "login: " und Sie müssen Ihren Benutzernamen eingeben, drücken Sie cr. Dann heißt es "Passwort:", und Sie müssen Ihr Passwort eingeben. Danach erhalten Sie "Last login: ... and a prompt". Wenn Sie es "dtruss", wird die Ausgabe nicht auf den Bildschirm geschrieben, sodass Sie nichts sehen, aber Sie müssen trotzdem Ihren Benutzernamen eingeben, die Eingabetaste und das Passwort drücken, die Eingabetaste drücken, um den Anmeldevorgang abzuschließen und zu sehen, wo es hängt . Wiederholen Sie einfach, was Sie getan haben, und geben Sie, ohne etwas zu sehen, den Benutzernamen ein, geben Sie ein, Passwort, geben Sie ein.

Der loginQuellcode des Befehls wurde von Apple veröffentlicht. Die Website ist macOS 10.13.3 Source . Der einzige erforderliche Download ist system_cmds-790.30.1. Nach dem Herunterladen kann das Projekt einfach geändert werden, um nur den loginBefehl zu erstellen. Das geänderte Projekt und loginder Befehl wurden in GitHub unter davidanderson61/system_cmds-10.13.3 abgelegt .

Die Idee hier ist, zu modifizieren login, um Debug-Informationen in die Konsole zu schreiben. Dies würde helfen, festzustellen, warum der loginBefehl hängt. Die Änderungen können von jedem vorgenommen werden, der teilnehmen möchte. Ich nahm an, das wäre ich gewesen.

Debug- loginBefehl installieren.

  1. Wählen Sie die neueste Version von der Website davidanderson61/system_cmds-10.13.3/releases aus .

  2. Laden Sie den Debug- loginBefehl in Ihren DownloadsOrdner herunter. Klicken Sie unter „Assets“ mit der rechten Maustaste loginund wählen Sie „Verknüpfte Datei herunterladen als“ und dann „Speichern“.

  3. Deaktivieren Sie teilweise den Systemintegritätsschutz (SIP). Der Befehl ist unten angegeben. Bevor Sie den Befehl eingeben, müssen Sie zu einem macOS Recover und dann zu einem Terminalfenster booten.

    csrutil  enable  --without  fs

  4. Geben Sie den unten angegebenen Befehl ein, um den ursprünglichen loginBefehl zu speichern. Falls login.orignalbereits vorhanden, können Sie diesen Schritt überspringen.

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

  5. Geben Sie die unten angegebenen Befehle ein, um den Debug login-Befehl zu kopieren und die richtigen Berechtigungen festzulegen.

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

  6. Aktivieren Sie den Systemintegritätsschutz (SIP). Geben Sie den folgenden Befehl ein. Danach sollten Sie neu starten.

    sudo  csrutil  clear

Konfigurieren Sie die Konsolenanwendung

Im Folgenden finden Sie die Schritte zum Konfigurieren der Konsolenanwendung, um nur Meldungen des loginBefehls anzuzeigen.

  1. Öffnen Sie die Konsolenanwendung.

  2. Fügen Sie eine PIDSpalte hinzu, wie unten gezeigt.

    g2

  3. Geben Sie loginin das Suchfeld ein.

    g3

    Während das Suchfeld den Fokus hat, drücken Sie die returnTaste . Das Suchfeld sollte sich wie unten gezeigt ändern.

    g8

  4. Wechseln Sie Anyzu Process, wie unten gezeigt.

    g4

  5. Liste Wechseln Sie Containszu Equals, wie unten gezeigt.

    g5

  6. Wählen Sie die SaveSchaltfläche aus. Wenn Sie nach "Suche speichern unter:" gefragt werden, geben Sie ein Loginund wählen Sie dann Save.

    g6

Die Ergebnisse sollten wie unten gezeigt aussehen. Wenn Sie die Konsolenanwendung das nächste Mal öffnen, müssen Sie nur die Schaltfläche „Anmelden“ auswählen.

g7

Anhang

Wie das GitHub-Repository erstellt wurde.

  1. Klicken Sie auf die system_cmds.xcodeprojin Xcode geöffnete Datei.
  2. Wählen Sie in der Menüleiste aus Source Control->Create Git Repositories....
  3. Wählen Sie in der Menüleiste aus Product->Scheme->New Scheme.... Als nächstes wählen Sie loginals Ziel und Name aus.
  4. Wählen Sie in der Menüleiste aus Project->Build.
  5. Beenden Sie Xcode.
  6. Melden Sie sich bei GitHub an und erstellen Sie ein neues Repository.
  7. Klicken Sie oben auf der Schnelleinrichtungsseite Ihres GitHub-Repositorys auf , g1um die Remote-Repository-URL zu kopieren.

  8. Geben Sie für ein Terminal-Anwendungsfenster den folgenden Befehl ein. <remote repository URL>Durch die im vorherigen Schritt kopierte URL ersetzen .

    git  remote  add  origin  <remote repository URL>

  9. Öffnen Sie das Projekt in Xcode und wählen Sie in der Menüleiste Source Control->Push....

Wie die erste Version erstellt wurde

  1. Geben Sie in einem Terminal-Anwendungsfenster die folgenden Befehle ein.

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

  2. Kopieren Sie den erstellten loginBefehl in Ihren DownloadsOrdner.

  3. Erstellen Sie in Ihrem GitHub-Konto eine neue Version als v1.0. ~/Downloads/loginAls Binärdatei anhängen .

Ich hatte dieses Problem auch beim Ausführen der sbt-Konsole in emacs. Immer wenn ich die sbt-Konsole verließ, indem ich einfach das Fenster beendete, anstatt die sbt-Konsole zuerst "schön" zu verlassen, führte dies dazu, dass ein Java-Prozess auch nach dem Schließen des Fensters hängen blieb und irgendwie verhinderte, dass neue Terminalsitzungen erstellt wurden. Ich habe den Java-Prozess vom Aktivitätsmonitor aus zwangsweise beendet, und das hängende Terminal wurde tatsächlich gestartet, sowohl innerhalb von Emacs als auch in einem neuen Tab.

Jetzt vergewissere ich mich einfach, dass ich mit dem Befehl exitor ctrl-d(oder ctrl-c ctrl-din emacs term/multi-term) sauber beende und dann das Fenster schließe.

  1. Überprüfen Sie, ob Ihr Prozess währenddessen wirklich hängtlogin
  2. Werfen Sie einen Blick auf den Aktivitätsmonitor und achten Sie auf rootProzesse (z. B. nano, emacs, vim), die Sie möglicherweise gestartet und nicht richtig beendet haben (Absturz, gerade beendetes Terminal usw.) und die noch laufen.
  3. Beenden Sie diese(n) Prozess(e) und die Anmeldung sollte sofort funktionieren.

Nur meine zwei Cent.

Ich habe das Terminus-Paket für Sublime Text installiert, mit dem ich Terminal in meinem Texteditor ausführen kann.

Durch das Schließen von Sublime Text konnte mein Terminal sofort wieder arbeiten.

Ich glaube nicht, dass dies zur Beantwortung der Frage beiträgt. Verhindert dies, dass das Terminal hängen bleibt, indem es innerhalb von Terminus ausgeführt wird? Selbst wenn dies der Fall ist, scheinen Sie hier ein anderes Problem zu lösen.
Mein normales Terminal würde aufgrund einiger Probleme mit Sublime Text nicht funktionieren

FWIW, ich hatte das gleiche Problem. Es würde nach dem Neustart behoben, aber ich wollte mir die Zeit sparen, dies mehrmals am Tag zu tun. Es begann nach der Verwendung einer bestimmten nodeJS-Umgebung, also ging ich in den Aktivitätsmonitor und bemerkte, dass ein Node-Prozess im Gange war. Das Beenden dieser Instanz hat das Problem für mich gelöst. Wenn also jemand, der dies erlebt, kürzlich begonnen hat, lokal mit node oder npm zu arbeiten, könnte das Ihr Problem sein.

War in meinem Fall ein verirrter "Java" -Prozess, aber das Beenden im Aktivitätsmonitor hat das Hängen des Terminals gestoppt!

Das Beenden einer streunenden nvim-Instanz hat dies für mich behoben. Ich nehme an, dies ist nicht spezifisch für nvim, aber etwas, das nvim in meinem Fall getan hat, hat Probleme verursacht. Ich würde im Aktivitätsmonitor nach einer fehl am Platz liegenden verwaisten Terminal-App suchen und diese beenden, wenn Sie eine finden.

In meinem Fall blieb das neue Terminalfenster nach der Anzeige hängen Last login: Tue Nov 24 18:31:39 on ttys001und der Titel des Terminalfensters zeigte manpath.

Es stellte sich heraus, dass dies geschah, weil ich meinen Xcode von 11.7 auf 12.2 aktualisiert hatte, aber die neuen Befehlszeilentools noch nicht installiert hatte. Nach dem Start von Xcode öffnete sich das Terminal ohne Probleme oder Verzögerungen.

Terminalanmeldung hängt
AntwortenHierDatenschutz-Bestimmungen1y, 0v