Connexion au terminal bloquée

Comme vous le savez sûrement, le dépannage est un processus d'élimination et nécessite souvent beaucoup de patience. J'aimerais essayer quelques choses pour essayer de résoudre ce problème pour vous.

1. Confirmez s'il bloque pendant la connexion

Si le processus bloque réellement pendant la connexion, cela implique que le processus est toujours en attente pour créer une session de connexion. En supposant que c'est le cas, alors il n'aurait pas encore essayé de démarrer le shell.

Pour confirmer cela, la prochaine fois que vous rencontrez ce problème, lancez le Moniteur d'activité pour vérifier si le shell est en cours d'exécution ou si vous ne voyez qu'un processus de connexion.

Une fois que vous avez eu l'occasion de le faire, revenez vers nous avec ce que vous avez trouvé.

REMARQUE:- Si vous avez d'autres terminaux ouverts, assurez-vous de vérifier le processus correspondant. Je suppose que le processus bloquant est celui avec le numéro d'identifiant de processus (PID) le plus élevé.

2. Quel est le titre du Terminal ?

La prochaine fois que vous rencontrez ce problème, pourriez-vous prendre note du titre de la fenêtre du Terminal et nous le rapporter ?

3. Arrêtez sudo

Vous mentionnez que redémarrer votre MBP résout toujours ce problème.

Cependant, la prochaine fois que vous rencontrez ce problème (peut-être après avoir fait ce que j'ai décrit au point 1 ci-dessus), je vous invite à essayer d'arrêter sudo depuis le Moniteur d'activité.

Une fois que vous avez essayé cela, dites-nous ce qu'il se passe.

4. Essayez de déplacer vos fichiers .bash*

Il est possible (pour diverses raisons) que vous ayez un fichier .bash_profile dans votre répertoire utilisateur et que cela cause des problèmes intermittents. C'est quelque chose dont vous n'êtes peut-être même pas conscient, mais vous pouvez utiliser Automator pour exécuter un script qui trouve et déplace tous les fichiers .bash.

Voici un script exemple pour cela :

cd ~

mkdir déplacé
pour F dans .bash*
faire
    mv $F déplacé
fait

Ce script déplace tous les fichiers commençant par .bash dans votre dossier utilisateur vers un sous-dossier déplacé> nouvellement créé.

_

Après avoir exécuté le script, vérifiez ce dossier et dites-nous si vous avez en fait des fichiers dedans.

REMARQUE:- Vous pouvez nommer le nouveau sous-dossier comme bon vous semble. Pour cela, il suffit de changer les deux occurrences de déplacé> dans le script par le libellé que vous souhaitez utiliser.

_

[MISE À JOUR]

Quelques autres choses à essayer.

5. Essayez de vider les fichiers *.asl

Si vous ne l'avez pas déjà fait, essayez de vider les fichiers *.asl. Pour ce faire, utilisez la commande suivante :

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

REMARQUE:- Cela peut prendre un certain temps car cela crée un nouveau shell. Une fois terminé, assurez-vous de quitter complètement le Terminal pour que les changements prennent effet.

6. Mode sans échec

Remarquez-vous une différence de comportement lorsque vous démarrez votre MBP en mode sans échec ? Pour démarrer en mode sans échec :

1. Éteignez complètement votre Mac
2. Redémarrez votre Mac
3. Appuyez immédiatement sur la touche Shift et maintenez-la enfoncée
4. Relâchez la touche Shift lorsque vous voyez la fenêtre de connexion (REMARQUE : Si vous avez activé FileVault, vous devrez peut-être vous connecter deux fois).
5. Une fois que votre MBP démarre, essayez d'utiliser le Terminal et voyez si vous parvenez toujours à reproduire le problème?
6. Une fois terminé, vous pouvez quitter le mode sans échec en redémarrant votre MBP normalement

7. Répertoire ouvert

Cela ne s'applique probablement pas dans votre cas puisque vous ne le mentionnez pas, mais si vous êtes connecté à un réseau Open Directory, cela pourrait également causer des problèmes. Habituellement, cela impliquerait seulement d'attendre environ 10 à 15 secondes, mais j'ai vu des rapports de connexions terminales prenant cinq minutes ou plus pour se terminer dans cette situation.

__

Cela semble être un ajustement parfait pour vous dépassant le maximum de processus par utilisateur (ou éventuellement le maximum de processus).

Sur une installation standard de macOS, vous obtenez 709 par utilisateur (ulimit -u) et 1064 processus maximum (sysctl -a | grep maxp)

Une façon simple d'augmenter ces limites est d'installer Server.app depuis l'App Store, puis de redémarrer. Vous pouvez également définir le mode performances pour des limites plus élevées.

Étant donné que vous n'avez pas décrit votre configuration (version et build du système d'exploitation), voici quelques conseils - assurez-vous de vérifier si SIP restreint votre capacité à modifier des fichiers si vous lisez certains des anciens articles sur la modification des limites sans recourir à l'installation de Server.app:

• Comment augmenter "ulimit -u" (processus utilisateur max)?
• 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

J'ai aussi vu cela depuis plusieurs mois maintenant. Extrêmement frustrant. La seule chose qui le corrige est de redémarrer.

• MBP mi-2015 (sans barre tactile)
• MacOS 10.12.6 beta

Parfois, les blocages de connexion se produisent après avoir interagi avec tmux.

J'ai essayé sans succès toutes les approches recommandées.

Je ne suis pas sûr si c'est lié, mais un lsof -p ID_LOGIN montre un fichier assez massif /private/var/db/dyld/dyld_shared_cache_x86_64h pour le processus de connexion bloqué.

Mise à jour le 29/08/2017:

Le problème persiste. Parfois, lorsque la machine se trouve dans un mauvais état, j'ai des fenêtres de terminal ouvertes qui sont déjà connectées avec succès et que je peux utiliser pour déboguer.

De nombreuses commandes ne s'exécutent pas correctement, mais elles montrent toutes un problème d'écriture (je pense à stdout). Par exemple, lorsque je lance ls -al, je vois ls: error d'écriture émis sur stderr. Lorsque je lance ls -al > /dev/null, rien n'est imprimé sur stderr.

Il est important de traiter le vrai problème et non seulement le symptôme. Alors essayez les suggestions suivantes et mettez à jour afin que nous puissions suggérer d'autres remèdes également.

1. Quel utilisateur possède le terminal?:
   Mon premier pressentiment est que cela peut être lié à la façon dont votre compte est configuré. Si le terminal essaie d'accéder aux ressources ou répertoires que seul l'utilisateur administrateur peut (si le vôtre est un compte non administrateur), cela peut entraîner un état de gel - ne vous permettant pas d'accéder au terminal. Alors assurez-vous que lorsque vous commencez une session de terminal, elle est locale à votre utilisateur et non à un autre utilisateur. Le fait que vous ne puissiez pas créer de processus sudo me dirige dans cette direction.

2. Tapez Control-Z ou Command-Z:
   Cette séquence de touches de contrôle suspend un programme qui peut être en cours d'exécution et vous donne un invite de commande shell. Maintenant vous pouvez entrer la commande jobs pour trouver le nom du programme, puis redémarrer le programme avec fg ou le terminer avec kill.

3. Appuyez sur Command-C:
   Cela interrompra si le terminal essaie d'exécuter un programme en arrière-plan. Essayez-le quelques fois. Notez si vous voyez une quelconque sortie

4. Tapez Control-Q:
   Si la sortie a été arrêtée avec Control-S, cela la redémarrera.

5. Obtenez un shell alternatif:
   Si vous voulez essayer un shell différent pendant quelques jours, leurs comportements peuvent parfois vous aider à comprendre le problème avec le Terminal étant donné s'ils agissent d'une certaine manière. Consultez ces liens ci-dessous pour des alternatives

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

Aidera à savoir ce qui suit, si ce n'est pas déjà mentionné:

• Comment initiez-vous la session du terminal? Est-ce via spotlight, une icône sur le bureau ou d'une autre manière?

• Que fait le terminal quand il se fige? Est-ce en train d'exécuter une commande (même commande à chaque fois avant qu'il se fige) ou se fige-t-il dès que vous démarrez une session de terminal/fenêtre.

• À quoi utilisez-vous généralement votre terminal? Si la majorité de votre utilisation concerne uniquement des commandes liées à git, je vous suggère d'utiliser quelque chose comme Github pour Mac car vous pouvez généralement faire la plupart des choses à partir de là.

Je voudrais essayer de désactiver SIP et la connexion dtrace pour trouver la cause racine (Pour désactiver et réactiver SIP, voir 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

En essayant de vous donner un exemple de sortie, je viens de découvrir que les choses sont bien plus simples que je ne le pensais. Pas besoin de désactiver SIP, il suffit de copier login.

dtruss renverra les appels système et cela pourrait donner un indice sur l'endroit où les choses se passent mal.

cp /usr/bin/login .
sudo ls

Entrez votre mot de passe. Ensuite, faites

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

entrez votre nom d'utilisateur, appuyez sur entrée

entrez votre mot de passe, appuyez sur entrée

entrez 'exit', appuyez sur entrée

et enfin téléchargez dtruss_login.txt sur par exemple https://gist.github.com/

Vous pouvez copier le contenu du fichier dans le presse-papiers comme ceci

cat dtruss_login.txt | pbcopy

Vous pouvez trouver un exemple de connexion ici : https://gist.github.com/wolframteetz/49c5188c9dfe68a3841fa18496679579

Le deuxième entier de chaque ligne est le temps que l'appel a pris.

Évidemment, ce serait génial si vous pouviez exécuter ceci lorsque la connexion se bloque, mais si je vous comprends bien, cela est impossible.... peut-être que vous ou quelqu'un d'autre a une idée sur comment 'dtruss login' lorsque le terminal se bloque?