Frage Chef-Client, der an npm hängt, wird bei node-gyp rebuild installiert


Ich habe ein Problem mit dem Laufen npm install von einem Kochrezept. Wenn ich es über die Befehlszeile ausführe, ist es in weniger als einer Minute fertig mit nur ein paar Warnungen im Zusammenhang mit package.json kein Repository-Feld (was sollte harmlos sein). Aber wenn ich es vom Chef aus führe, hängt es mit der letzten Zeilenausgabe zurück zur Kommandozeile:

* execute[npm-install-app] action run

Was ist dieser Ressourcenblock im Rezept:

execute "npm-install-app" do
  cwd "#{home}/#{prefix}#{app}"
  command "npm --registry #{priv['url']}:#{priv['port']}#{priv['path']} install --cache #{home}/.npm --tmp #{home}/tmp > npm-run.log 2>&1"
  user node['nodejs']['user']
  action :run
end

Woher #{home} erweitert sich zu /home/nodejs und der Benutzer ist nodejs.

Wie Sie sehen können, habe ich die Ausgabe in eine Datei mit einer Datei umgeleitet > npm-run.log 2>&1. Die Ausgabedatei erhält die Ausgabe des Befehls npm install (anders als die Befehlszeile), und das letzte, was durchkommt, ist folgendes:

-- a bunch of 200's and 304s, like this --
npm http 304 http://my.private.npm.amazonaws.com/registry/_design/app/_rewrite/esprima

kerberos@0.0.3 install /home/nodejs/my-app/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos
(node-gyp rebuild 2> builderror.log) || (exit 0)

kerberos ist eine Abhängigkeit von einem Modul, auf das wir angewiesen sind, aber wir verwenden Kerberos nicht selbst. Ich entnehme anderen Quellen, dass npm node-gyp ausführt, um eine Version der App zu kompilieren, die nicht auf dem npm-Server verfügbar ist.

Es wird in diesem Zustand für 2 Stunden sitzen, bis chef shellout ein Timeout registriert und es einen schwerwiegenden Fehler zeigt. ps -e zeigt an, dass npm immer noch läuft, wenn der Chef-Client noch läuft, und die Unterbrechung des Chef-Clients führt dazu, dass npm aus der Prozessliste verschwindet, was nahelegt, dass npm immer noch denkt, dass es immer noch sinnvolle Arbeit leistet. (Nebenbei bemerkt, während ich Verbindungsprobleme hatte, war ich geneigt zu fragen diese Frage. Dies ist mit hoher Wahrscheinlichkeit möglich npm install ist das zugrunde liegende Problem der anderen Frage, aber ich denke, dass sie eine gesonderte Betrachtung rechtfertigen.)

Bearbeiten: Den Chef-Kunden mit einem -l debug fügt eine kleine Menge an Informationen hinzu /var/log/chef/client.log Datei, die im Grunde bestätigt, dass die npm install Befehl ist die letzte Ressource, die vor dem Aufhängen ausgeführt wird:

[2014-01-09T22:49:28+00:00] INFO: Processing execute[npm-install-app] action run (my-app::default line 111)
[2014-01-09T22:49:28+00:00] DEBUG: Platform ubuntu version 12.04 found

Habe ich richtig gedacht, dass das || (Ausgang 0) wirft den Chef ShellOut Anbieter einen erfolgreichen Ausgang zu erkennen? Kann ich irgendetwas dagegen tun?

Bearbeiten 2: Chef hat gerade aus einem Lauf mit -l debug gesetzt, und immer noch nur Log-Informationen über das Timeout.

[2014-01-10T00:26:56+00:00] ERROR: execute[npm-install-app] (my-app::default line 111) had an error: Mixlib::ShellOut::CommandTimeout: command timed out:
---- Begin output of npm --registry http:my.private.npm.amazonaws.com:5984/registry/_design/app/_rewrite install --cache /home/nodejs/.npm --tmp /home/nodejs/tmp > npm-run.log 2>&1 ----
STDOUT:
STDERR:
---- End output of npm --registry http://ec2-54-221-190-191.compute-1.amazonaws.com:5984/registry/_design/app/_rewrite install --cache /home/nodejs/.npm --tmp /home/nodejs/tmp > npm-run.log 2>&1 ----

Aber! Ein weiterer Knoten wurde gerade nach ~ 5 Minuten erfolgreich beendet und hatte diesen Inhalt in der npm-run.log Datei:

> kerberos@0.0.3 install /home/nodejs/spicoli-authorization/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos
> (node-gyp rebuild 2> builderror.log) || (exit 0)

make: Entering directory `/home/nodejs/spicoli-authorization/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos/build'
  SOLINK_MODULE(target) Release/obj.target/kerberos.node
  SOLINK_MODULE(target) Release/obj.target/kerberos.node: Finished
  COPY Release/kerberos.node
make: Leaving directory `/home/nodejs/spicoli-authorization/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos/build'

Ich kann mir nicht vorstellen, warum es einen so großen Leistungsunterschied geben würde, beide Server laufen auf Amazon-ec2-Instanzen. Vielleicht gibt es einen Unterschied der Berechtigungen zwischen dem Home-Verzeichnis auf den funktionierenden und defekten Servern ... Ich werde diesen Winkel untersuchen.


5
2018-01-09 22:33


Ursprung


Antworten:


Naja, endlich habe ich meinen Idiotenhut ausgezogen und am richtigen Ort nach dem Baumstamm gesucht. Der Befehl sagt sogar 2> builderror.logAlso würdest du denken, das wäre genug von einem Trinkgeld find für eine Datei mit diesem Namen, aber es ist mir immer noch nicht eingefallen. Dies ist sehr frustrierend, da der Befehl node-gyp scheinbar in den Kerberos-Quellcode integriert ist und Fehler in jedem aufrufenden Prozess (wie zB Chef oder irgendein anderes Build-Tool, das automatisch npm-installieren möchte) automatisch ausblendet.

Hier ist, was es sagt (immer und immer wieder für ca. 350 MB, also der Spaß kleine Hang! Gute Sache mein Chef Rezept löschte das Verzeichnis bei jedem Lauf verwendet, oder das könnte viel schwieriger zu diagnostizieren):

gyp WARN EACCES attempting to reinstall using temporary dev dir "/root/tmp/.node-gyp"
gyp WARN EACCES user "root" does not have permission to access the dev dir "/root/tmp/.node-gyp/0.10.22"

Das Seltsame ist, dass node-gyp mit Dateien um diesen Ort herum arbeitet: /home/nodejs/my-app/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos/, und mein Befehl npm install wird als ausgeführt nodejs Benutzer, aber es versucht immer noch zu schreiben /root als die root Benutzer! Da muss etwas nicht stimmen, denn root Darn hat auch Berechtigungen für dieses Verzeichnis.

ubuntu@amazonaws:~$ sudo ls -la /
-- snip --
drwx------  4 root root  4096 Jan  7 22:50 root

ubuntu@amazonaws:~$ sudo ls -la /root
total 24
drwx------  4 root root 4096 Jan  7 22:50 .
drwxr-xr-x 23 root root 4096 Jan  7 22:46 ..
-rw-r--r--  1 root root 3106 Apr 19  2012 .bashrc
drwx------  2 root root 4096 Jan  7 22:50 .cache
-rw-r--r--  1 root root  140 Apr 19  2012 .profile
drwx------  2 root root 4096 Jan  7 22:46 .ssh

Zuerst dachte ich, ich müsste nur die Berechtigungen für die /home/nodejs Verzeichnis, aber das wird ein Follow-up zu den Node-Gyp-Entwicklern, denke ich.

Zumindest erklärt das, warum es funktioniert, wenn ich den Befehl npm-install als einen anderen Benutzer (der über sudo-Berechtigungen verfügt) als bare ausführen kann.

Aktualisieren: Ich habe schließlich daran gearbeitet, indem ich die npm-Installation als root ausgeführt habe und dann chownund chmoddie installierten Dateien. Die Chef-Ressourcenblöcke, die ich für dieses Aussehen verwendet habe, sehen ungefähr so ​​aus:

  # Recursively chown and chmod all files just created
  execute "fixup #{home}/#{prefix}#{app} owner" do
    command "find ./ -exec sudo chown #{node[:nodejs][:user]}:#{node[:nodejs][:user]} {} +"
    cwd "#{home}/#{prefix}#{app}"
  end

  execute "fixup #{home}/#{prefix}#{app} file permissions" do
    command "find ./ -type f -exec sudo chmod 644 {} +"
    cwd "#{home}/#{prefix}#{app}"
  end

  execute "fixup #{home}/#{prefix}#{app} directory permissions" do
    command "find ./ -type d -exec sudo chmod 755 {} +"
    cwd "#{home}/#{prefix}#{app}"
  end

Dies behebt nicht die Unzulänglichkeiten von node-gyp in der Berechtigungsabteilung, die ich weiterverfolgen und eine andere Antwort veröffentlichen werde, wenn ich eine direkte Antwort an dieser Stelle bekomme.


5
2018-01-10 15:23



Dieses Problem hängt ungefähr 10 Minuten (fühlt sich an) auf meinem OSX, aber es ist geschafft, zu beenden. Ich habe 'sudo npm install' verwendet, um Mungo aus dem Terminal zu installieren, das in der WebStorm IDE gestartet wurde. (Habe nicht ohne Sudo versucht.)

-
> kerberos@0.0.3 install .../Documents/.../node_modules/mongoose/node_modules/mongodb/node_modules/kerberos
> (node-gyp rebuild 2> builderror.log) || (exit 0)

\
> bson@0.2.12 install .../Documents/.../node_modules/mongoose/node_modules/mongodb/node_modules/bson
> (node-gyp rebuild 2> builderror.log) || (exit 0)

<<<< HERE IS THE STRANGE HANGING >>>>


  CXX(target) Release/obj.target/bson/ext/bson.o
  SOLINK_MODULE(target) Release/bson.node
  SOLINK_MODULE(target) Release/bson.node: Finished
mongoose@3.8.17 node_modules/mongoose
├── regexp-clone@0.0.1
├── hooks@0.2.1
├── mpath@0.1.1
├── mpromise@0.4.3
├── ms@0.1.0
├── muri@0.3.1
├── sliced@0.0.5
├── mquery@0.8.0 (debug@0.7.4)
└── mongodb@1.4.9 (readable-stream@1.0.32, kerberos@0.0.3, bson@0.2.12)

$ ls -al


1
2017-10-01 17:51