Pourquoi git échoue sur le push/fetch avec "Too many open files" (trop de fichiers ouverts).

Question

Je rencontre un problème avec Git où je reçois le message suivant :

> git fetch
error: cannot create pipe for ssh: Too many open files
fatal: unable to fork

Les administrateurs du système ont augmenté ma limite de fichiers, mais cela n'a pas corrigé le problème. De plus, je n'ai pas de problème pour créer de nouveaux fichiers avec vi.

Lorsque j'essaie de pousser une nouvelle branche, j'obtiens un message similaire :

git push origin test_this_broken_git error : cannot create pipe : Trop de fichiers ouverts fatal : send-pack : impossible de bifurquer du démultiplexeur à bande latérale

Quelqu'un pourrait-il me dire exactement pourquoi cela se produit ? Je n'ai pas apporté de modifications récentes à ma configuration git et je l'ai vérifié manuellement.

Answer 1

Il existe deux messages d'erreur similaires :

EMFILE: Too many open files
ENFILE: Too many open files in system

On dirait que tu as EMFILE ce qui signifie que le nombre de fichiers d'un processus individuel est dépassé. Il faut donc vérifier si vi peut ouvrir des fichiers n'est pas pertinent. vi utilisera son propre tableau de fichiers, séparé. Vérifiez vos limites avec :

$ ulimit -n
1024

Ainsi, sur mon système, il y a une limite de 1024 fichiers ouverts dans un seul processus. Vous ne devriez pas avoir besoin de demander à votre administrateur système (n'utilisez pas l'acronyme SA, il est trop opaque ; si vous devez abréger, utilisez "sysadmin") de relever cette limite.

Vous pouvez vérifier quels fichiers Git ouvre en lançant Git sous strace .

Il peut s'agir d'un bogue dans Git ou dans une bibliothèque, ou d'une ancienne version de quelque chose, ou encore de quelque chose de plus bizarre. Essayez strace d'abord pour voir quels fichiers il ouvre, et vérifier si Git ferme ces fichiers.

Mise à jour de Hazok :

Après avoir appliqué les recommandations ci-dessus, il s'avère que l'erreur était due à un trop grand nombre d'objets détachés. Il y avait trop d'objets en vrac parce que git gc n'était pas exécuté assez souvent.

Answer 2

Pourquoi cela s'est-il produit ?

De la documentation git :

Lorsqu'il y a approximativement plus que ce nombre d'objets libres dans le dépôt, git gc --auto les emballera. Certaines commandes de Porcelain utilisent cette commande pour effectuer un garbage collection léger de temps en temps. La valeur par défaut est de 6700.

Ici, "Quelques commandes de porcelaine" comprend git push , git fetch etc. Donc si la limite maximale de fichiers ouverts ulimit -n < 6700, vous serez éventuellement bloqué par git gc --auto une fois que vous avez ~6700 objets libres dans un seul dépôt git.

Je suis pressé. Comment le réparer ?

Si vous avez les permissions suffisantes pour ajuster l'ulimit du système :

$ sudo ulimit -n 8192

Sinon, vous pouvez désactiver git gc en fixant git config gc.auto=0 de sorte que vous puissiez pousser vos modifications locales sur le site distant, supprimer le dépôt et le cloner à nouveau sans perdre des milliers d'objets.

Comment pouvons-nous éviter que cela ne se reproduise ?

Définir git config --global gc.auto=200 où 200 est une valeur inférieure à votre limite maximale de fichiers ouverts. Si vous avez choisi une valeur trop petite, git gc serait trop fréquente, alors choisissez judicieusement.

Si vous définissez gc.auto=0 les objets en vrac ne seront jamais emballés, sauf si vous exécutez git gc manuellement. Il peut donc y avoir des centaines de milliers de fichiers accumulés dans le même répertoire, ce qui peut poser problème, surtout pour les utilisateurs de disques durs mécaniques ou de Windows. (Voir aussi : Combien de fichiers dans un répertoire sont trop nombreux ? y Est-il possible (du point de vue des performances) d'avoir des centaines ou des milliers de fichiers dans le même répertoire Linux ? ).