Ho uno strano problema sul mio nuovo MacBook Pro (fine 2016, touch bar).

Funziona bene e quindi, dopo averlo usato per un po ', l'apertura di nuove finestre Terminale non funziona perché si loginblocca. Il riavvio risolve il problema.

Questo sembra essere un problema che alcune persone hanno avuto, quindi ho già provato tutte le loro soluzioni (da 1 e [2] ):

1. Rimozione ~/Library/Preferences/com.apple.Terminal.plist
2. Impostare la mia shell predefinita su un'altra shell (da /bin/zsha /bin/sho /bin/bash)
3. La rimozione o la pulizia il mio .profile, .zprofile... Questo non funziona e posso confermare che il problema si verifica prima che la shell è anche invocata, perché se io echo HEYcome la prima linea della mia .zshenvquesto non è nemmeno raggiunto. Deve logincausare i problemi. Anche la modifica /etc/profileper aggiungere un'eco in alto non mostra nulla
4. La modifica delle Run command:impostazioni nella configurazione del mio Terminale su qualcosa del genere echo foonon funziona (lasciare Run inside shellselezionata o deselezionata non cambia nulla).

Altre note:

• Come [2] , ssh-add -Knon persiste le chiavi tra i riavvii, qualcosa con cui non ho mai avuto problemi prima.
• La console non mostra errori o avvisi sospetti.
• L'apertura di una nuova Terminalfinestra sembra creare il file tty ( /dev/ttys<number>).
• In questo caso, non importa se utilizzo Terminal.app o iTerm.app
• Ho un'installazione abbastanza pulita (ho appena ricevuto il mio laptop, non ho ripristinato alcun backup, ho solo installato alcune app con brew installe brew cask install).

È davvero difficile eseguire il debug perché non riesco a riprodurlo e spesso non riesco ad aprire un nuovo terminale per nemmeno provare a scoprire cosa sta succedendo.

Qualcuno ha qualche consiglio?

Aggiornare:

Usando iTerm, sono stato in grado di ottenere una shell impostando il comando start su /bin/bash. In questa shell, tuttavia, sudonon funziona. E si blocca (senza mostrare il prompt) ed ctrl-Ce ctrl-Dnon fare il lavoro quando si blocca.

Utilizzando alcuni altri programmi anche non funziona in questo guscio: nodeo /usr/local/bin/nodeentrambi blocco. Per quanto posso dire, sono i programmi che sono dentro /usr/local/bin.

Aggiornamento 2:

brew list --full-name risulta in questi pacchetti:

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

Aggiornamento 3:

Questi punti sono in corrispondenza della risposta di @ Monomeeth:

1. Quando accade, un loginelemento viene visualizzato nel monitor attività. (Forza) Chiudendolo chiude anche la finestra del Terminale che era sospesa. La chiusura manuale della finestra non comporta la loginscomparsa del processo in Activity Monitor.

2. Il titolo del terminale è Terminal — login — term big — ttys001 — 89x18 — ⌘1, dove si term bigtrova il nome delle impostazioni.

3. Non viene visualizzato alcun sudoprocesso in Activity Monitor. Posso creare un sudoprocesso aprendo iTerm.app (che usa bash) ed eseguendo sudo echo oklì. Non può essere Quit, ma Force Quit funziona e lo uccide:

   bash-3.2 $ sudo echo ok Ucciso: 9

Aggiornamento 4:

Quando accade, in esecuzione loginda un guscio che è ancora disponibile fa il lavoro, mentre l' loginin gusci più recenti sembra bloccarsi.

Aggiornamento 5:

Di recente ho ottenuto un nuovo laptop (MacBook Pro 2017, nessuna Touch Bar) e il problema persiste.

Ho anche cambiato shell: ora lo sto usando fishcon una bella configurazione vaniglia. Penso che escluda il guscio come colpevole.

Il sistema operativo è stato anche aggiornato a 10.13.3 (17D47) High Sierra.

Ho provato a installare il meno possibile su questa macchina:

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

Non sono sicuro di cosa possa essere adesso. Le uniche app a cui riesco a pensare sono Divvyo Apptivatedato che sembrano entrambe obsolete. Questa è l'intersezione di ciò che è stato installato sul vecchio vs il nuovo computer:

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

Aggiornamento 6:

Inoltre, ecco uno screenshot:

Aggiornamento 7:

Il mio env in genere assomiglia a questo:

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

Come sicuramente sai, la risoluzione dei problemi è un processo di eliminazione e spesso richiede un po 'di pazienza. Mi piacerebbe provare alcune cose per provare ad andare fino in fondo per te.

1. Confermare che si blocchi durante l'accesso

Se il processo a cui è bloccato è realmente durante l' accesso , ciò implica che il processo è ancora in attesa di creare una sessione di accesso. Supponendo che sia così, allora non avrebbe ancora provato ad avviare la shell.

Per confermare ciò, la prossima volta che si verifica questo problema avviare Activity Monitor per verificare se la shell è in esecuzione o se viene visualizzato solo un processo di accesso .

Una volta che hai avuto la possibilità di farlo, riferisci con quello che hai trovato.

NOTA: - Se hai altri terminali aperti, assicurati di controllare il processo corrispondente. La mia ipotesi è che il processo di sospensione sia quello con il numero PID (Process ID) più alto.

2. Qual è il titolo del Terminale?

La prossima volta che riscontri questo problema, puoi prendere nota di quale sia il titolo della finestra Terminale e riportare indietro?

3. Uccidi sudo

Dichiari che il riavvio del tuo MBP risolve sempre questo problema.

Tuttavia, la prossima volta che hai questo problema (forse dopo aver fatto quello che ho descritto in 1 sopra), mi piacerebbe che tu provassi a uccidere sudo da Activity Monitor.

Una volta provato, facci sapere cosa succede.

4. Prova a spostare i tuoi file .bash *

È possibile (per vari motivi) che potresti avere un file .bash_profile nella tua directory utente e questo causa problemi intermittenti. Questo è qualcosa di cui potresti anche non essere a conoscenza, ma puoi usare Automator per eseguire uno script che trova e sposta qualsiasi file .bash.

Ecco uno script di esempio per farlo:

cd ~

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

Questo script sposta tutti i file che iniziano con .bash nella cartella home in una sottocartella spostata appena creata .

Dopo aver eseguito lo script, controlla questa cartella e facci sapere se in realtà ci sono dei file.

NOTA: - È possibile etichettare la nuova sottocartella come desiderato. Per fare ciò, basta cambiare le due occorrenze di spostate nello script in qualsiasi etichetta che si desidera utilizzare.

[AGGIORNARE]

Qualche altra cosa da provare.

5. Prova a cancellare i file * .asl

Se non l'hai già fatto, prova a cancellare i file * .asl. Per fare ciò, utilizzare quanto segue:

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

NOTA: - Questo potrebbe richiedere del tempo poiché crea una nuova shell. Al termine, assicurarsi di chiudere completamente il Terminale affinché le modifiche abbiano effetto.

6. Modalità provvisoria

Noti qualche differenza nel comportamento quando avvii il tuo MBP in modalità provvisoria? Per avviare in modalità provvisoria:

1. Spegni completamente il Mac
2. Riavvia il tuo Mac
3. Premere immediatamente il Shifttasto e tenerlo premuto
4. Rilascia la Shiftchiave quando viene visualizzata la finestra di accesso (NOTA: se FileVault è abilitato, potrebbe essere necessario accedere due volte).
5. Una volta avviato il tuo MBP prova a utilizzare Terminal e vedi se riesci ancora a replicare il problema?
6. Al termine, è possibile uscire dalla modalità provvisoria riavviando l'MBP normalmente

7. Apri la directory

Questo probabilmente non si applica al tuo caso poiché non lo menzioni, ma se sei connesso a una rete Open Directory questo potrebbe anche causare problemi. Di solito questo implicherebbe solo un'attesa di circa 10-15 secondi, ma ho visto i resoconti degli accessi ai terminali impiegare cinque o più minuti per completare in questa situazione.

Sembra una soluzione perfetta per te che supera i processi massimi per utente (o eventualmente i processi massimi).

Su un'installazione macOS di serie ottieni 709 per utente ( ulimit -u) e 1064 processi max ( sysctl -a | grep maxp)

Un modo semplice per risolverli è installare Server.app dall'App Store e quindi riavviare. È inoltre possibile impostare la modalità di prestazione per limiti più elevati.

Dato che non hai descritto la tua configurazione (versione e build del sistema operativo), ecco alcuni suggerimenti: assicurati di verificare la presenza di SIP che limitano la possibilità di modificare i file se leggi alcuni degli articoli più vecchi sulla modifica dei limiti senza ricorrere all'installazione del server. app:

• Come faccio ad aumentare "ulimit -u" (max processi utente)?
• 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

Lo vedo anche da diversi mesi ormai. Estremamente frustrante. L'unica cosa che lo risolve è il riavvio.

• MBP di metà 2015 (nessuna barra di tocco)
• MacOS 10.12.6 beta

A volte i blocchi di accesso si verificano dopo aver interagito con tmux.

Ho provato senza successo tutti gli approcci consigliati.

Non sono sicuro che sia correlato, ma lsof -p LOGIN_PIDmostra un file piuttosto massiccio /private/var/db/dyld/dyld_shared_cache_x86_64hper il processo di accesso bloccato.

Aggiornamento del 29/08/2017:

Il problema persiste. A volte quando la macchina si trova in cattivo stato, ho finestre aperte del terminale che sono già connesse correttamente e che posso usare per il debug.

Molti comandi non vengono eseguiti correttamente, ma mostrano tutti uno schema di difficoltà nella scrittura (a stdout, sto pensando). Ad esempio, quando corro ls -al, vedo ls: write erroremesso su stderr. Quando corro ls -al > /dev/null, nulla viene stampato su stderr.

È importante trattare il vero problema e non solo il sintomo. Quindi prova i seguenti suggerimenti e aggiorna in base a ciò che può suggerire anche ulteriori rimedi.

1. Quale utente possiede il terminale? : Il
   mio primo sospetto è che ciò possa essere correlato alla configurazione del tuo account. Se il terminale sta tentando di accedere alle risorse o alle directory che solo l'utente amministratore può (se il tuo è un account non amministratore), ciò può portare a uno stato di congelamento, che non ti consente di accedere al terminale. Quindi vai avanti e assicurati che quando inizi una sessione terminale, è locale per il tuo utente e non per un altro utente. Il fatto che non sia possibile creare un processo sudo, mi sta indicando questa direzione.

2. Digitare Control-Z o Command-Z:
   questa sequenza di tasti di controllo sospende un programma che potrebbe essere in esecuzione e fornisce un prompt della shell. Ora puoi inserire il comando jobs per trovare il nome del programma, quindi riavviare il programma con fg o terminarlo con kill.

3. Premi Comando-C :
   questo si interromperà se il terminale sta tentando di eseguire un programma in background. Provalo un paio di volte. Nota se vedi qualche output

4. Digitare Control-Q :
   se l'uscita è stata interrotta con Control-S, questo verrà riavviato.

5. Ottieni una shell alternativa :
   se vuoi provare una shell diversa per alcuni giorni, i loro comportamenti possono talvolta aiutarti a capire il problema con Terminal dato se agiscono in un certo modo. Controlla questi link qui sotto per alternative

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

Aiuterà a conoscere quanto segue, se non già menzionato:

• Come stai iniziando la sessione terminale? È tramite riflettori o un'icona del desktop o in qualche altro modo?

• Cosa sta facendo il terminale quando si blocca? È nel mezzo dell'esecuzione di un comando (lo stesso comando ogni volta prima che si blocchi) o si blocca dal momento in cui si avvia una sessione / finestre del terminale.

• Per cosa usi di solito il tuo terminale? Se la maggior parte del tuo utilizzo è solo per i comandi relativi a Git, ti suggerirei di usare Something like Github per Mac, dato che di solito puoi fare la maggior parte delle cose da lì.

Vorrei provare a disabilitare SIP e accedere a dtrace per trovare la causa principale (Per disabilitare e riattivare SIP, vedere 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

Cercando di darti un esempio, ho appena scoperto che le cose sono molto più semplici di quanto pensassi. Non è necessario disabilitare SIP, basta copiare l'accesso.

dtuss restituirà le chiamate di sistema e potrebbe dare un suggerimento su dove le cose vanno male.

cp /usr/bin/login .
sudo ls

dare la tua password. Quindi fa

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

inserisci il tuo nome utente, premi invio

inserisci la tua password, premi invio

inserire 'esci', premere invio

e infine carica dtruss_login.txt, ad esempio https://gist.github.com/

È possibile copiare il contenuto del file negli Appunti in questo modo

cat dtruss_login.txt | pbcopy

Puoi trovare un esempio di login qui: https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

Il secondo numero intero in ciascuna linea è il tempo impiegato dalla chiamata.

Certo, sarebbe fantastico se tu potessi eseguire questo quando il login si blocca, ma se ti ho capito bene, questo è impossibile .... forse tu o qualcun altro ha un'idea su come "controllare il login" quando il terminale si blocca ?

Il logincodice sorgente del comando è stato pubblicato da Apple. Il sito Web è macOS 10.13.3 Fonte . L'unico download richiesto è system_cmds-790.30.1. Una volta scaricato, il progetto può essere facilmente modificato per creare solo il logincomando. Il progetto e il logincomando modificati sono stati inseriti in GitHub su davidanderson61 / system_cmds-10.13.3 .

L'idea qui è di modificare loginper scrivere le informazioni di debug sulla console. Ciò contribuirebbe a determinare perché il logincomando si blocca. Le modifiche potrebbero essere apportate a chiunque desideri partecipare. Pensavo che sarei stato io.

Installa il logincomando di debug .

1. Seleziona l'ultima versione dal sito web davidanderson61 / system_cmds-10.13.3 / release .

2. Scarica il logincomando debug nella tua Downloadscartella. In "Risorse", fai clic con il pulsante destro del mouse logine seleziona "Scarica file collegato come", quindi seleziona "Salva".

3. Parzialmente, disabilitare System Integrity Protection (SIP). Il comando è dato di seguito. Prima di immettere il comando, dovrai avviare un Ripristino macOS , quindi una finestra Terminale.

   csrutil  enable  --without  fs

4. Immettere il comando indicato di seguito per salvare il logincomando originale . Se login.orignalesiste già, puoi omettere questo passaggio.

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

5. Immettere i comandi indicati di seguito per copiare il logincomando debug e impostare le autorizzazioni appropriate.

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

6. Abilita System Integrity Protection (SIP). Immettere il comando seguente. Successivamente, è necessario riavviare.

   sudo  csrutil  clear

Configurare l'applicazione console

Di seguito sono riportati i passaggi per configurare l'applicazione Console per mostrare solo i messaggi dal logincomando.

1. Apri l'applicazione console.

2. Aggiungi una PIDcolonna, come mostrato di seguito.

   

3. Inserisci loginnel campo Cerca.

   

   Mentre il campo Cerca è attivo, premere il returntasto. Il campo di ricerca dovrebbe cambiare a quanto mostrato di seguito.

   

4. Passare Anya Process, come mostrato di seguito.

   

5. Elenco Cambia Containsin Equals, come mostrato di seguito.

   

6. Seleziona il Savepulsante Quando viene richiesto "Salva come:", inserire Login, quindi selezionare Save.

   

I risultati dovrebbero apparire come mostrato di seguito. La prossima volta che apri l'applicazione Console, dovrai solo selezionare il pulsante "Accedi".

Appendice

Come è stato creato il repository GitHub.

1. Fai clic sul system_cmds.xcodeprojfile aperto in Xcode.
2. Dalla barra dei menu, selezionare Source Control->Create Git Repositories....
3. Dalla barra dei menu, selezionare Product->Scheme->New Scheme.... Quindi, selezionare logincome destinazione e nome.
4. Dalla barra dei menu, selezionare Project->Build.
5. Esci da Xcode.
6. Accedi a GitHub e crea un nuovo repository.
7. Nella parte superiore della pagina di installazione rapida del repository GitHub, fare clic per copiare l'URL del repository remoto.

8. Per una finestra dell'applicazione Terminale, immettere il seguente comando. Sostituisci <remote repository URL>con URL copiato nel passaggio precedente.

   git  remote  add  origin  <remote repository URL>

9. Apri il progetto in Xcode e dalla barra dei menu, seleziona Source Control->Push....

Come è stata creata la prima versione

1. Dalla finestra di un'applicazione Terminale, immettere i seguenti comandi.

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

2. Copia il logincomando integrato nella tua Downloadscartella.

3. Dal tuo account GitHub, crea una nuova versione come v1.0. Allega ~/Downloads/logincome binario.

Ho avuto questo problema anche durante l'esecuzione della console sbt in emacs. Ogni volta che sono uscito dalla console sbt semplicemente uccidendo la finestra invece di uscire dalla console sbt prima, ha causato un processo java anche dopo la chiusura della finestra e in qualche modo ha impedito la creazione di nuove sessioni terminal. Ho forzato a uccidere il processo java dal monitor delle attività e il terminale sospeso si è effettivamente avviato, all'interno di emacs e in una nuova scheda.

Ora, mi accerto semplicemente di uscire bene usando il comando exito ctrl-d(o ctrl-c ctrl-din emacs term/multi-term), quindi uccidere la finestra.

1. Controlla se il tuo processo si blocca davvero durante login
2. Dai un'occhiata a Activity Monitor e fai attenzione root fai processi (ad es. Nano, emacs, vim) che potresti aver avviato e non chiuso correttamente (crash, appena ucciso il terminale, ecc.) E che sono ancora in esecuzione.
3. Kill questo / i processo / i e il login dovrebbe funzionare immediatamente.

Solo i miei due centesimi.

Ho installato il pacchetto Terminus per Sublime Text, che mi consente di eseguire il terminale nel mio editor di testo.

La chiusura di Sublime Text ha immediatamente permesso al mio terminale di riprendere a funzionare.

FWIW, ho avuto lo stesso problema. Si sarebbe risolto dopo il riavvio, ma volevo risparmiare tempo per farlo più volte al giorno. È iniziato dopo aver utilizzato un particolare ambiente nodeJS, quindi sono entrato nel monitoraggio delle attività e ho notato un processo del nodo in corso. Uccidere quell'istanza ha risolto il problema per me, quindi se qualcuno ha riscontrato di recente ha iniziato a lavorare con node o npm localmente, questo potrebbe essere il tuo problema.

Uccidere un'istanza di NVID vagante ha risolto questo problema per me. Suppongo che questo non sia specifico per NVIM, ma qualcosa che NVVIM nel mio caso stava facendo causava problemi. Vorrei cercare un'app terminal orfana fuori posto nel monitor delle attività e ucciderla se ne trovassi una.