2014-01-09 11 views
5

Ich habe ein Problem mit npm install von einem Koch Rezept ausgeführt. Wenn ich es über die Befehlszeile ausführe, ist es in weniger als einer Minute mit ein paar Warnungen in Bezug auf package.json no repository field (die harmlos sein sollte) beendet. Aber wenn ich es vom Chef laufen, hängt es mit der letzten Zeile Ausgang zurück in die Befehlszeile wie folgt aus:Chef-Client hängt an Npm installieren bei Node-Gyp-Umbau

* execute[npm-install-app] action run 

Welche dieser Ressourcenblock im Rezept ist:

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 

Wo #{home} erweitert out zu /home/nodejs und der Benutzer ist nodejs.

Wie Sie sehen können, leitete ich die Ausgabe in eine Datei in eine Datei mit > npm-run.log 2>&1 um. Die Ausgabedatei wird die Ausgabe des NPM installiert Befehl geschrieben (im Gegensatz zu der Befehlszeile), und das letzte, was durchkommt, ist dies:

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

[email protected] 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 angewiesen sind wir auf , aber wir benutzen 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 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 zumindest noch sinnvolle Arbeit leistet. (Nebenbei bemerkt, während ich Verbindungsprobleme hatte, war ich geneigt, this question zu fragen. Es gibt ein hohes Maß an Wahrscheinlichkeit, dass dieses npm install das zugrundeliegende Problem der anderen Frage ist, aber ich denke, dass sie separate Betrachtung rechtfertigen.)

Edit: mit einem -l debug der Koch-Client-Laufe fügt eine kleine Menge von Informationen an die /var/log/chef/client.log-Datei, die bestätigt im Wesentlichen, dass der npm install Befehl die letzte Ressource vor hanging ausgeführt werden soll:

[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 

Am Ich denke, dass das || (Ausgang 0) wirft den Chef ShellOut Anbieter einen erfolgreichen Ausgang zu erkennen? Kann ich irgendetwas dagegen tun?

Edit 2: Chef zeitlich nur mit -l debug Satz von einem Lauf aus, und bekam nur noch Informationen über die Timeout anmelden.

[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 nur erfolgreich nach ca. 5 Minuten beendet und hatte diesen Inhalt in der Datei npm-run.log:

> [email protected] 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 nicht denken kann, warum es wäre ein so großer Performance-Unterschied, beiden Server laufen auf amazon kleine EC2-Instanzen . Vielleicht gibt es einen Unterschied der Berechtigungen zwischen dem Home-Verzeichnis auf den funktionierenden und defekten Servern ... Ich werde diesen Winkel untersuchen.

+0

Haben Sie eine Lösung zu finden? Ich sehe nichts unmittelbar Offensichtliches, das dies verursachen würde. – sethvargo

+0

@sethvargo Ich habe noch keine Fortschritte gemacht. Ich versuche gerade einen Weg zu finden, mehr Logs aus dem 'node-gyp rebuild' Prozess zu erfassen, aber [ihre Dokumentation] (https://github.com/TooTallNate/node-gyp) erwähnt nichts darüber. Ich muss vielleicht zum Quellcode-Tauchen gehen oder eine Alias-Magie ausprobieren. –

Antwort

5

Nun nahm ich endlich meinen Idiotenhut ab und suchte den Baumstamm an der richtigen Stelle.Der Befehl sagt sogar 2> builderror.log, also würden Sie denken, dass wäre genug von einem Tipp zu nur find für eine Datei mit diesem Namen, aber es kam mir immer noch nicht vor. 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 wieder ca. ~ 350 MB, also der Spaß kleine Hang! Gute Sache mein Chef Rezept löschte das Verzeichnis bei jedem Lauf verwendet, oder dies hätte 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 merkwürdige ist, dass node-gyp mit Dateien in der Nähe arbeiten: /home/nodejs/my-app/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos/, und meine npm Befehl installieren als nodejs Benutzer ausgeführt wird, aber es ist immer noch versuchen, /root als root Benutzer zu schreiben ! Da muss etwas nicht stimmen, denn root darn hat auch Berechtigungen für dieses Verzeichnis.

[email protected]:~$ sudo ls -la/
-- snip -- 
drwx------ 4 root root 4096 Jan 7 22:50 root 

[email protected]:~$ 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 Berechtigungen reparieren auf dem /home/nodejs Verzeichnis, aber das wird nehmen eine den Knoten-gyp Entwickler verfolgen, glaube ich.

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

Update: ich schließlich um das funktionierte durch die npm lassen Installation als root ausführen und dann chown ‚ing und chmod‘ die installierten Dateien ing. Die Chef-Ressourcenblöcke benutzte ich für diesen Look etwas wie folgt 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 nicht node-gyp die Mängel in der Berechtigungsabteilung beheben, die ich auch weiterhin verfolgen und eine andere Antwort zu hinterlassen, wenn ich eine direkte Antwort bekommen auf diese Front.

+0

Kühl. Ich bin froh, dass du das meiste davon herausgefunden hast. Vergessen Sie nicht, Ihre Antwort in 2 Tagen zu akzeptieren :) – sethvargo

+0

Danke Seth. Heh, hoffentlich habe ich bis dahin eine funktionierende Lösung :-p –

1

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

- 
> [email protected] install .../Documents/.../node_modules/mongoose/node_modules/mongodb/node_modules/kerberos 
> (node-gyp rebuild 2> builderror.log) || (exit 0) 

\ 
> [email protected] 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 
[email protected] node_modules/mongoose 
├── [email protected] 
├── [email protected] 
├── [email protected] 
├── [email protected] 
├── [email protected] 
├── [email protected] 
├── [email protected] 
├── [email protected] ([email protected]) 
└── [email protected] ([email protected], [email protected], [email protected]) 

$ ls -al

+0

Es sieht so aus, als ob Sie das gleiche Problem haben. Haben Sie sich den Inhalt von 'builderror.log' angesehen? Wenn die Fehlermeldungen übereinstimmen, haben Sie die Schritte in meiner Antwort oben versucht? Wenn die Nachrichten nicht übereinstimmen, möchten Sie wahrscheinlich [Eine neue Frage stellen] (http://stackoverflow.com/questions/ask). –