Cli: [BUG] Erreur `lchown` lors de l'accès au fichier de verrouillage d'installation lors de l'exécution de plusieurs installations en parallèle.

Créé le 18 nov. 2019  ·  16Commentaires  ·  Source: npm/cli

Quoi / Pourquoi

NPM échoue en raison de la création (?) de verrous (et non de package-lock.json) lors de l'installation.

Lorsque

  • Semble se produire lors de plusieurs installations parallèles.

Comment

Comportement actuel

  • Échouera occasionnellement dans les fichiers de verrouillage lchown npm (pas package-lokc.json).

Étapes à suivre pour reproduire

  • Voir la section where .
  • Il est possible de reproduire ceci en effectuant les étapes suivantes :

    • Cloner mon fork de DT et vérifier ma branche liée à ce PR

    • Initialiser via npm install

    • Courez npm test node

Comportement attendu

  • Le verrouillage n'a pas échoué.

Qui

  • Incertain

Les références

Commentaire le plus utile

Après quelques débogages, j'ai trouvé le problème autour de https://github.com/npm/cli/blob/latest/lib/utils/correct-mkdir.js#L31. Si npm est exécuté simultanément, plusieurs processus appellent chownr contre ~/.npm/_locks . L'implémentation de chownr lit tous les fichiers du répertoire et essaie d'appliquer chown à chacun des fichiers. Certains fichiers peuvent être supprimés entre readdir et lchown et cela conduit à ENOENT .

Tous les 16 commentaires

Se produit également localement sur Linux avec les mêmes étapes de reproduction, par exemple

npm ERR! syscall lchown
npm ERR! path /home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, lchown '/home/nathansa/.npm/_locks/staging-33722a1ecded5100.lock'
npm ERR! enoent This is related to npm not being able to find a file.

Semble se produire moins lorsque je passe au nœud 11.0.0 + npm 6.7.0.

Le nœud 11.0.0 est une version vraiment étrange car le nœud 11 est en fin de vie depuis un certain temps. Essayez peut-être le LTS 12.13.1 actuel ? Ou c'est peut-être l'ancienne version de NPM fournie avec le nœud 11 qui évite cela.

Ouais, je voyageais juste en arrière à travers les versions que j'ai installées jusqu'à ce que je trouve une version non problématique. L'ancienne version de npm est très probablement la variable.

@sandersn peut-être effectuer une recherche binaire manuelle dans les versions ? 😛

Rencontrer ce bogue lors de l'utilisation cohérente de Lerna, ce qui cause malheureusement des problèmes dans notre processus de construction.
Message d'erreur:

lerna ERR! npm install stderr:
  | npm ERR! code ENOENT
  | npm ERR! syscall lchown
  | npm ERR! path /root/.npm/_locks/staging-3f138bd09ee0de58.lock
  | npm ERR! errno -2
  | npm ERR! enoent ENOENT: no such file or directory, lchown '/root/.npm/_locks/staging-3f138bd09ee0de58.lock'
  | npm ERR! enoent This is related to npm not being able to find a file.
  | npm ERR! enoent

C'est lors de l'utilisation de l'image docker node:latest-alpine , qui utilise actuellement les versions :
nœud : 12.13.1
npm : 6.12.1

Je peux confirmer que cela m'arrive également avec le nœud v13.2.0 et npm 6.13.4.

Quelqu'un a une solution temporaire pour cela? Comme cela bloque certains de nos déploiements. :(

@midudev temp mitigation consiste à ne pas exécuter npm i en parallèle ou au moins à réduire considérablement la simultanéité.
Lorsque vous traitez avec le repo DT en le limitant à 2 installations parallèles, cela réduit le nombre d'échecs d'environ 90 %.

Merci @SimonSchick. Oui... L'absence de simultanéité semble résoudre le problème, mais le temps nécessaire à l'installation des packages est considérablement augmenté. :(

Je me demande si l'équipe npm est au courant de ce problème car cela fonctionnait bien auparavant. De s'il s'agit d'un problème causé par certains changements internes sur le nœud.

Bonjour, nous avons le même problème.
Je suis presque sûr qu'il s'agit d'une sorte de problème de condition de course.

La solution temporaire consiste à rétrograder à [email protected] .

J'ai testé presque toutes les versions de 6.10.2 à la dernière 6.13.6 et le problème est là.
Je peux confirmer que le bogue n'est PAS lié à la version nodejs , il est juste lié à la version npm .

Nous rencontrons le même problème pour npm i contre https://github.com/strongloop/loopback-next , qui est un lerna monorepo. npm i au niveau racine déclenche l'installation de npm pour plusieurs packages en parallèle. La réduction de la simultanéité réduit également les chances d'exécuter le problème signalé.

Nous pouvons obtenir plus d'informations sur le fichier de verrouillage avec NODE_DEBUG=lockfile npm i .

Après quelques débogages, j'ai trouvé le problème autour de https://github.com/npm/cli/blob/latest/lib/utils/correct-mkdir.js#L31. Si npm est exécuté simultanément, plusieurs processus appellent chownr contre ~/.npm/_locks . L'implémentation de chownr lit tous les fichiers du répertoire et essaie d'appliquer chown à chacun des fichiers. Certains fichiers peuvent être supprimés entre readdir et lchown et cela conduit à ENOENT .

@isaacs Veuillez me faire savoir si https://github.com/raymondfeng/chownr/commit/e4c7b59fe4142995ae36c71de3435d2e2a7e4319 est le bon endroit pour résoudre ce problème. Si c'est le cas, j'essaierai d'ajouter quelques tests et de soumettre un PR.

@raymondfeng Cela ressemble à un changement raisonnable. Oui, veuillez envoyer un PR à chownr.

@isaacs PR soumis - https://github.com/npm/cli/issues/496. Merci pour votre réponse rapide.

Cette page vous a été utile?
0 / 5 - 0 notes