简体   繁体   English

挂在npm上的厨师客户端安装在node-gyp rebuild

[英]Chef client hanging on npm install at node-gyp rebuild

I'm having a problem with running npm install from a chef recipe. 从主厨配方运行npm install遇到问题。 When I run it from the command line, it finishes fine in under a minute with just a few warnings related to package.json no repository field (which should be harmless). 当我从命令行运行它时,它在一分钟内完成,只有一些与package.json没有存储库字段相关的警告(应该是无害的)。 But when I run it from chef, it hangs with the last line output back to the command line as this: 但是当我从chef运行它时,它会挂起最后一行输出回命令行,如下所示:

* execute[npm-install-app] action run

Which is this resource block in the recipe: 配方中的这个资源块是:

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

Where #{home} expands out to /home/nodejs and the user is nodejs . #{home}扩展到/home/nodejs ,用户是nodejs

As you can see, I redirected the output to a file to a file with > npm-run.log 2>&1 . 如您所见,我使用> npm-run.log 2>&1将输出重定向到文件到文件。 The output file gets the output of the npm install command written to it (unlike the command line), and the last thing that comes through is this: 输出文件获取写入它的npm install命令的输出(与命令行不同),最后一件事是:

-- 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 is a dependency of one module we're relying on, but we aren't using kerberos ourselves. kerberos是我们依赖的一个模块的依赖,但我们自己并没有使用kerberos。 I gather from other sources that npm is running node-gyp to compile a version of the app that isn't available packaged on the npm server. 我从其他来源收集到npm正在运行node-gyp来编译在npm服务器上打包的不可用的应用程序版本。

It will sit in that state for 2 hours until chef shellout registers a timeout and it shows a fatal error. 它将在该状态下保持2小时,直到大厨shellout注册超时并显示致命错误。 ps -e will show npm is still running when chef-client is still running, and interrupting chef-client will cause npm to disappear from the process list, which suggests that npm still thinks it is still doing meaningful work, at least. ps -e将显示当chef-client仍在运行时npm仍在运行,并且中断chef-client将导致npm从进程列表中消失,这表明npm仍然认为它仍然在做有意义的工作,至少。 (On a side note, while I was having connection problems, I was inclined to ask this question . There is a high degree of probability that this npm install is the underlying problem of the other question, but I think they warrant separate consideration.) (另一方面,当我遇到连接问题时,我倾向于问这个问题 。这个npm install很可能是另一个问题的根本问题,但我认为他们需要单独考虑。)

Edit: Running the chef-client with a -l debug adds a tiny amount of information to the /var/log/chef/client.log file, which basically confirms that the npm install command is the last resource to be executed before hanging: 编辑:使用-l debug运行chef-client会向/var/log/chef/client.log文件添加少量信息,这基本上确认npm install命令是挂起之前要执行的最后一个资源:

[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 I right in thinking that the || 我是否正确地认为|| (exit 0) is throwing off the chef ShellOut provider detecting a successful exit? (退出0)抛出主厨ShellOut提供商检测成功退出? Is there anything I can do about it? 我能做些什么吗?

Edit 2: Chef just timed out from a run with -l debug set, and still only got log information on the timeout. 编辑2: Chef刚从带有-l debug集的运行-l debug ,并且仍然只获得有关超时的日志信息。

[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 ----

But! 但! Another node just successfully finished after ~5 minutes and had this content in the npm-run.log file: 另一个节点在约5分钟后成功完成,并在npm-run.log文件中包含此内容:

> 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'

I can't think of why there would be such a huge performance difference, both servers are running on amazon small ec2 instances. 我想不出为什么会出现如此巨大的性能差异,两台服务器都运行在亚马逊的小型ec2实例上。 Maybe there is a permissions difference between the home directory on the working and broken servers... I will investigate that angle. 也许在工作和损坏的服务器上的主目录之间存在权限差异......我将调查该角度。

Well I finally took off my idiot hat and looked for the log in the right place. 好吧,我终于脱掉了我的白痴帽子,在正确的地方寻找原木。 The command even says 2> builderror.log , so you'd think that would be enough of a tip to just find for a file of that name, but it still didn't occur to me. 该命令甚至说2> builderror.log ,所以你认为只需find一个具有该名称的文件的提示即可,但它仍然没有发生在我身上。 This is very frustrating, because the node-gyp command is apparently built into the kerberos source code and it silently hides errors from any calling process (like Chef, or any other build tool that might want to npm-install automatically). 这非常令人沮丧,因为node-gyp命令显然内置于kerberos源代码中,它默默地隐藏来自任何调用进程的错误(如Chef或任何其他可能需要自动进行npm安装的构建工具)。

Here is what it says (over and over again for about ~350 MB, thus the fun little hang! Good thing my Chef recipe was deleting the directory used on every run, or this could have gotten way harder to diagnose): 这就是它所说的(一遍又一遍地约为350 MB,因此有趣的小挂!我的厨师食谱是删除每次运行时使用的目录,或者这可能更难以诊断):

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"

The curious thing is that node-gyp is working with files around this location: /home/nodejs/my-app/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos/ , and my npm install command is running as the nodejs user, but it's still trying to write to /root as the root user! 奇怪的是node-gyp正在处理这个位置周围的文件: /home/nodejs/my-app/node_modules/mongoose-q/node_modules/mongoose/node_modules/mongodb/node_modules/kerberos/ ,我的npm install命令是作为nodejs用户运行,但它仍然尝试以root用户身份写入/root Something must be amiss with this, because root darn well has permissions for that directory. 对此必须有些不妥,因为root darn具有该目录的权限。

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

At first, I thought I would just have to fix up permissions on the /home/nodejs directory, but this will take a follow up to the node-gyp developers, I think. 起初,我认为我只需要修复/home/nodejs目录的权限,但我认为这将需要跟进node-gyp开发人员。

At least this explains why if I run the npm-install command bare as a different user (who has sudo permissions) it works. 至少这解释了为什么如果我将npm-install命令作为不同的用户(具有sudo权限)运行,它可以工作。

Update: I eventually worked around this by letting the npm install run as root and then chown 'ing and chmod 'ing the installed files. 更新:我最终解决了这个问题,让npm install以root用户身份运行,然后chownchmod '安装的文件。 The Chef resource blocks I used for this look something like this: 我用于此的Chef资源块看起来像这样:

  # 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

This does not fix node-gyp's shortcomings in the permissions department, which I will continue to pursue and post another answer if I get a direct response on that front. 这并没有解决node-gyp在权限部门中的缺点,如果我在这方面得到直接回复,我将继续追求并发布另一个答案。

This problem hangs about 10 minutes (felt like) on my OSX but it managed to finish. 这个问题在我的OSX上挂了大约10分钟(感觉就像),但它设法完成了。 I used 'sudo npm install' to install mongoose from the terminal launched inside WebStorm IDE. 我使用'sudo npm install'从WebStorm IDE内部启动的终端安装mongoose。 (Haven't tried without sudo.) (没有sudo就试过了。)

-
> 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 $ ls -al

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM