J'ai un problème étrange sur mon nouveau MacBook Pro (fin 2016, barre tactile).

Cela fonctionne bien, puis, après l'avoir utilisé pendant un certain temps, l'ouverture de nouvelles fenêtres de terminal ne fonctionne pas car il se loginbloque. Le redémarrage résout le problème.

Cela semble être un problème que d'autres personnes ont eu, alors j'ai déjà essayé toutes leurs solutions (de 1 et [2] ):

1. Suppression ~/Library/Preferences/com.apple.Terminal.plist
2. Définir mon shell par défaut sur un autre shell (de /bin/zshà /bin/shou /bin/bash)
3. Retrait ou nettoyage mon .profile, .zprofile... Cela ne fonctionne pas et je peux confirmer que le problème se produit avant que le shell est même invoqué, parce que si je echo HEYla première ligne de mon .zshenvcela même pas atteint. Cela doit être loginà l'origine des problèmes. L'édition /etc/profilepour ajouter un écho en haut n'affiche également rien
4. Changer le Run command:paramètre dans ma configuration Terminal Server en quelque chose comme echo fooça ne fonctionne pas non plus (laisser Run inside shellcoché ou décoché ne change rien).

Autres notes:

• Comme [2] , ssh-add -Kne persiste pas les clés entre les redémarrages, chose avec laquelle je n'ai jamais eu de problème auparavant.
• La console n'affiche aucune erreur ou avertissement suspect.
• L'ouverture d'une nouvelle Terminalfenêtre semble créer un fichier tty ( /dev/ttys<number>).
• Lorsque cela se produit, peu importe si j'utilise Terminal.app ou iTerm.app
• J'ai une installation assez propre (je viens de recevoir mon ordinateur portable, je n'ai pas restauré de sauvegardes, j'ai juste installé des applications avec brew installet brew cask install).

C'est vraiment difficile à déboguer car je ne peux pas le reproduire et souvent je ne peux pas ouvrir un nouveau terminal pour même essayer de savoir ce qui se passe.

Quelqu'un a-t-il des conseils?

Mise à jour:

En utilisant iTerm, j'ai pu obtenir un shell en définissant la commande start sur /bin/bash. Dans cette coquille, cependant, sudone fonctionne pas. Il se bloque (sans afficher l'invite) ctrl-Cet ctrl-Dne fait aucun travail lorsqu'il se bloque.

L' utilisation des autres programmes ne fonctionne pas non plus dans cette coquille: nodeou les /usr/local/bin/nodedeux hang. Pour autant que je sache, ce sont les programmes qui sont en cours /usr/local/bin.

Mise à jour 2:

brew list --full-name résultats dans ces packages:

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

Mise à jour 3:

Ces points correspondent à la réponse de @ Monomeeth:

1. Lorsque cela se produit, un loginélément apparaît dans le moniteur d'activité. (Forcer) Le quitter ferme également la fenêtre du terminal qui était suspendue. La fermeture manuelle de la fenêtre ne fait pas disparaître le loginprocessus dans le moniteur d'activité.

2. Le titre du terminal est Terminal — login — term big — ttys001 — 89x18 — ⌘1, où term bigest le nom des paramètres.

3. Aucun sudoprocessus n'apparaît dans le moniteur d'activité. Je peux créer un sudoprocessus en ouvrant iTerm.app (qui utilise bash) et en sudo echo oky exécutant . Il ne peut pas être Quitter, mais Forcer à quitter fonctionne et le tue:

   bash-3.2 $ sudo echo ok Tués: 9

Mise à jour 4:

Quand il arrive, en cours d' exécution logind'un obus qui est encore disponible ne le travail, tandis que les logindans des coquilles plus récents semble se bloquer.

Mise à jour 5:

J'ai récemment obtenu un nouvel ordinateur portable (MacBook Pro 2017, pas de Touch Bar) et le problème persiste.

J'ai également changé de coque: j'utilise maintenant fishune jolie configuration vanille. Je pense que cela exclut la coquille comme coupable.

Le système d'exploitation a également été mis à jour vers 10.13.3 (17D47) High Sierra.

J'ai essayé d'installer le moins possible sur cette machine:

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

Je ne sais pas ce que cela peut être maintenant. Les seules applications auxquelles je peux penser sont Divvyou Apptivatecar elles semblent toutes deux dépassées. C'est l'intersection de ce qui a été installé sur l'ancienne vs la nouvelle machine:

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

Mise à jour 6:

En outre, voici une capture d'écran:

Mise à jour 7:

Mon env ressemble généralement à ceci:

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

Comme vous le savez sûrement, le dépannage est un processus d'élimination et nécessite souvent un peu de patience. J'aimerais essayer quelques choses pour essayer d'aller au fond des choses pour vous.

1. Confirmez qu'il se bloque pendant la connexion

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

Pour le confirmer, la prochaine fois que vous rencontrerez ce problème, lancez Activity Monitor 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, rapportez 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 suspendu est celui qui a le plus grand numéro d'identification de processus (PID).

2. Quel est le titre du terminal?

La prochaine fois que vous rencontrez ce problème, pouvez-vous prendre note du titre de la fenêtre du terminal et faire un rapport?

3. Tuez sudo

Vous déclarez que le redémarrage de 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 ci-dessus), j'aimerais que vous essayiez de tuer sudo à partir du moniteur d'activité.

Une fois que vous avez essayé, faites-nous savoir ce qui 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, ce qui provoque des problèmes intermittents. Vous ne le savez peut-être même pas, mais vous pouvez utiliser Automator pour exécuter un script qui trouve et déplace tous les fichiers .bash.

Voici un exemple de script pour ce faire:

cd ~

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

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

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

REMARQUE: - Vous pouvez étiqueter le nouveau sous-dossier comme vous le souhaitez. Pour ce faire, remplacez simplement les deux occurrences de déplacées dans le script par le libellé que vous souhaitez utiliser.

[MISE À JOUR]

Encore des choses à essayer.

5. Essayez d'effacer les fichiers * .asl

Si ce n'est pas déjà fait, essayez d'effacer les fichiers * .asl. Pour ce faire, utilisez les éléments suivants:

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

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

6. Mode sans échec

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

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

7. Open Directory

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

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

Sur une installation stock de macOS, vous obtenez 709 ulimit -uprocessus par utilisateur ( ) et 1064 max ( sysctl -a | grep maxp)

Un moyen simple de les augmenter consiste à installer Server.app à partir de l'App Store, puis à redémarrer. Vous pouvez également définir le mode de performance pour des limites plus élevées.

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

• Comment puis-je 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
• /server/15564/where-are-the-default-ulimits-specified-on-os-x-10-5

Je le vois aussi depuis plusieurs mois maintenant. Extrêmement frustrant. La seule chose qui le corrige est le redémarrage.

• Mi-2015 MBP (pas de barre tactile)
• MacOS 10.12.6 beta

Parfois, la connexion se bloque après avoir interagi avec tmux.

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

Je ne sais pas si c'est lié, mais un lsof -p LOGIN_PIDaffiche un fichier assez volumineux /private/var/db/dyld/dyld_shared_cache_x86_64hpour le processus de connexion bloqué.

Mise à jour du 29/08/2017:

J'ai toujours le problème. Parfois, lorsque la machine est en mauvais état, j'ai des fenêtres de terminal ouvertes qui sont déjà connectées avec succès que je peux utiliser pour déboguer.

De nombreuses commandes ne s'exécutent pas correctement, mais elles montrent toutes une tendance à avoir du mal à écrire (sur stdout, je pense). Par exemple, lorsque je cours ls -al, je vois ls: write errorémis vers stderr. Quand je cours ls -al > /dev/null, rien n'est imprimé sur stderr.

Il est important de traiter le vrai problème et pas seulement le symptôme. Essayez donc les suggestions suivantes et mettez-les à jour afin de pouvoir également suggérer d'autres solutions.

1. Quel utilisateur possède le terminal? :
   Mon premier pressentiment est que cela peut être lié à la configuration de votre compte. Si le terminal essaie d'accéder aux ressources ou aux répertoires que seul l'utilisateur administrateur peut (si le vôtre est un compte non administrateur), cela peut conduire à un état de gel - ne vous permettant pas d'accéder au terminal. Alors allez-y et assurez-vous que lorsque vous commencez une session de terminal, elle est locale pour votre utilisateur et non pour un autre utilisateur. Le fait que vous ne puissiez pas créer un processus sudo me pointe 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 une invite de shell. Vous pouvez maintenant 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 Commande + C :
   cela interrompra si le terminal essaie d'exécuter un programme en arrière-plan. Essayez-le plusieurs fois. Notez si vous voyez une 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 Terminal si 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, s'il n'est pas déjà mentionné:

• Comment lancez-vous la session de terminal? Est-ce via Spotlight ou une icône du bureau ou d'une autre manière?

• Que fait le terminal lorsqu'il se bloque? Est-ce au milieu de l'exécution d'une commande (même commande à chaque fois avant qu'elle ne se bloque) ou elle se bloque juste à partir du moment où vous démarrez une session / fenêtre de terminal.

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

J'essaierais de désactiver la connexion SIP et 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 beaucoup plus simples que je ne le pensais. Pas besoin de désactiver SIP, copiez simplement la connexion.

dtuss renverra les appels système et il pourrait donner un indice sur les problèmes.

cp /usr/bin/login .
sudo ls

donnez votre mot de passe. Alors fais

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 enter

et enfin télécharger dtruss_login.txt sur 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 correspond au temps pris par l'appel.

Bien sûr, ce serait génial si vous pouviez exécuter cela lorsque la connexion se bloque, mais si je vous comprends bien, c'est impossible .... ?

Le logincode source de la commande a été publié par Apple. Le site Web est la source de macOS 10.13.3 . Le seul téléchargement requis est system_cmds-790.30.1. Une fois téléchargé, le projet peut être facilement modifié pour ne générer que la logincommande. Le projet et la logincommande modifiés ont été placés dans GitHub à davidanderson61 / system_cmds-10.13.3 .

L'idée ici est de modifier loginpour écrire des informations de débogage sur la console. Cela aiderait à déterminer pourquoi la logincommande se bloque. Les modifications pourraient être apportées à toute personne souhaitant participer. J'ai supposé que ça aurait été moi.

Installez la logincommande de débogage .

1. Sélectionnez la dernière version sur le site Web davidanderson61 / system_cmds-10.13.3 / releases .

2. Téléchargez la logincommande de débogage dans votre Downloadsdossier. Sous "Ressources", faites un clic droit loginet sélectionnez "Télécharger le fichier lié sous", puis sélectionnez "Enregistrer".

3. Désactivez partiellement la protection de l'intégrité du système (SIP). La commande est donnée ci-dessous. Avant d'entrer la commande, vous devrez démarrer sur une récupération macOS , puis sur une fenêtre de terminal.

   csrutil  enable  --without  fs

4. Entrez la commande ci-dessous pour enregistrer la logincommande d' origine . S'il login.orignalexiste déjà, vous pouvez omettre cette étape.

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

5. Entrez les commandes ci-dessous pour copier la logincommande de débogage et définir les autorisations appropriées.

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

6. Activez la protection de l'intégrité du système (SIP). Entrez la commande suivante. Ensuite, vous devez redémarrer.

   sudo  csrutil  clear

Configurer l'application console

Vous trouverez ci-dessous les étapes de configuration de l'application console pour afficher uniquement les messages de la logincommande.

1. Ouvrez l'application console.

2. Ajoutez une PIDcolonne, comme indiqué ci-dessous.

   

3. Entrez logindans le champ Rechercher.

   

   Pendant que le champ Rechercher est activé, appuyez sur la returntouche. Le champ de recherche doit changer comme indiqué ci-dessous.

   

4. Passez Anyà Process, comme indiqué ci-dessous.

   

5. Remplacez la liste Containspar Equals, comme indiqué ci-dessous.

   

6. Sélectionnez le Savebouton. Lorsque vous êtes invité à "Enregistrer la recherche sous:", entrez Login, puis sélectionnez Save.

   

Les résultats doivent apparaître comme indiqué ci-dessous. La prochaine fois que vous ouvrirez l'application Console, il vous suffira de sélectionner le bouton "Connexion".

appendice

Comment le référentiel GitHub a été créé.

1. Cliquez sur le system_cmds.xcodeprojfichier ouvert dans Xcode.
2. Dans la barre de menus, sélectionnez Source Control->Create Git Repositories....
3. Dans la barre de menus, sélectionnez Product->Scheme->New Scheme.... Ensuite, sélectionnez logincomme cible et nom.
4. Dans la barre de menus, sélectionnez Project->Build.
5. Quittez Xcode.
6. Connectez-vous à GitHub et créez un nouveau référentiel.
7. En haut de la page de configuration rapide de votre référentiel GitHub, cliquez pour copier l'URL du référentiel distant.

8. Pour une fenêtre d'application Terminal, entrez la commande suivante. Remplacez <remote repository URL>par l'URL copiée à l'étape précédente.

   git  remote  add  origin  <remote repository URL>

9. Ouvrez le projet dans Xcode et dans la barre de menus, sélectionnez Source Control->Push....

Comment la première version a été créée

1. Dans une fenêtre d'application Terminal, entrez les commandes suivantes.

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

2. Copiez la logincommande intégrée dans votre Downloadsdossier.

3. À partir de votre compte GitHub, créez une nouvelle version en tant que v1.0. Attachez ~/Downloads/logincomme binaire.

J'ai également rencontré ce problème lors de l'exécution de la console sbt dans emacs. Chaque fois que je quittais la console sbt en tuant simplement la fenêtre au lieu de quitter la console sbt "bien" en premier, cela provoquait un blocage du processus java même après la fermeture de la fenêtre et empêchait en quelque sorte la création de nouvelles sessions de terminal. J'ai tué de force le processus java depuis le moniteur d'activité, et le terminal suspendu a réellement démarré, depuis emacs ainsi que dans un nouvel onglet.

Maintenant, je m'assure de bien quitter la commande exitou ctrl-d(ou ctrl-c ctrl-ddans emacs term/multi-term), puis de tuer la fenêtre.

1. Vérifiez si votre processus se bloque vraiment pendant login
2. Jetez un œil au moniteur d'activité et surveillez les rootprocessus (par exemple, nano, emacs, vim) que vous pourriez avoir lancés et ne pas quitter correctement (planter, juste tuer le terminal, etc.) et qui sont toujours en cours d'exécution.
3. Tuez ce (s) processus et la connexion devrait fonctionner immédiatement.

Juste mes deux cents.

J'ai installé le package Terminus pour Sublime Text, qui me permet d'exécuter le terminal dans mon éditeur de texte.

La fermeture de Sublime Text a immédiatement permis à mon terminal de recommencer à fonctionner.

FWIW, j'ai eu ce même problème. Cela résoudrait après le redémarrage, mais je voulais gagner du temps à le faire plusieurs fois par jour. Cela a commencé après avoir utilisé un environnement nodeJS particulier, alors je suis allé dans le moniteur d'activité et j'ai remarqué un processus de nœud en cours. Tuer cette instance a résolu le problème pour moi, donc si quelqu'un expérimentant cela a récemment commencé à travailler avec node ou npm localement, cela pourrait être votre problème.

Tuer une instance nvim errante a corrigé cela pour moi. Je suppose que ce n'est pas spécifique à nvim mais quelque chose que nvim faisait dans mon cas a causé des problèmes. Je chercherais une application de terminal orpheline hors de propos dans le moniteur d'activité et la tuerais si vous en trouvez une.