挂在npm上的Chef客户端挂载在node-gyp重建上 [英] Chef client hanging on npm install at node-gyp rebuild

问题描述

从厨师食谱中运行 npm install 时遇到问题。当我从命令行运行它时，它在不到一分钟的时间内就完成了，并且只显示了一些与 package相关的警告.json没有存储库字段（应该无害）。但是，当我从Chef运行它时，它会与最后一行输出一起挂回命令行，如下所示：

I'm having a problem with running npm install from a chef recipe. 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). But when I run it from chef, it hangs with the last line output back to the command line as this:

* 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

其中＃{home} 扩展到 / home / nodejs ，而用户为 nodejs 。

Where #{home} expands out to /home/nodejs and the user is nodejs.

您可以看到，我将输出重定向到一个文件，该文件使用> npm-run.log 2>& 1 。输出文件将写入npm install命令的输出（与命令行不同），最后通过的内容是：

As you can see, I redirected the output to a file to a file with > 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:

-- 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 是一个依赖项我们所依赖的一个模块，但是我们自己并没有使用kerberos。我从其他来源收集到npm正在运行node-gyp来编译npm服务器上不提供的应用程序版本。

kerberos is a dependency of one module we're relying on, but we aren't using kerberos ourselves. 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.

它将位于该版本中状态持续2小时，直到Chef Shellout注册超时，并显示致命错误。 ps -e 将显示厨师客户端仍在运行时npm仍在运行，中断厨师客户端会使npm从进程列表中消失，这表明npm仍在运行认为它至少仍在做有意义的工作。 （附带说明，当我遇到连接问题时，我倾向于问此问题。 npm安装很有可能是另一个问题的根本问题，但我认为他们需要单独考虑。）

It will sit in that state for 2 hours until chef shellout registers a timeout and it shows a fatal error. 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. (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.)

编辑：使用 -l调试运行chef-client会为服务器添加少量信息 /var/log/chef/client.log 文件，该文件基本上确认 npm install 命令是最后一个资源要在挂起之前执行：

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:

[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

我是在想|| （退出0）正在淘汰主厨ShellOut提供程序，检测到成功退出？我有什么能做的吗？

Am I right in thinking that the || (exit 0) is throwing off the chef ShellOut provider detecting a successful exit? Is there anything I can do about it?

编辑2：主厨刚刚在 -l的运行中超时调试集，并且仍然仅在超时时获得日志信息。

Edit 2: Chef just timed out from a run with -l debug set, and still only got log information on the 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 ----

但是！大约5分钟后，另一个节点刚刚成功完成，并且在 npm-run.log 文件中包含了以下内容：

But! Another node just successfully finished after ~5 minutes and had this content in the npm-run.log file:

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

我想不出为什么会有如此巨大的性能差异，两台服务器都在亚马逊小型ec2实例上运行。也许工作的服务器和损坏的服务器上的主目录之间存在权限差异...我将对此进行研究。

I can't think of why there would be such a huge performance difference, both servers are running on amazon small ec2 instances. Maybe there is a permissions difference between the home directory on the working and broken servers... I will investigate that angle.

推荐答案

好吧，我终于脱下了笨蛋的帽子，在正确的位置寻找了日志。该命令甚至说 2> builderror.log ，所以您认为只要找到该名称的文件即可，只需查找就足够了，但是仍然没有不会发生在我身上。这非常令人沮丧，因为node-gyp命令显然内置在kerberos源代码中，并且它无声地隐藏了任何调用进程（例如Chef或任何其他想要自动npm-install的构建工具）中的错误。

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. 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).

这里是它的意思（一遍又一遍，大约350 MB，这很有趣，有点挂死了！好吧，我的厨师食谱正在删除每次运行时使用的目录，或者这样可能很难诊断）：

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):

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"

奇怪的是，node-gyp正在处理以下位置的文件： / home / nodejs / my-app / node_modules / mongoose-q / node_modules / mongoose / node_modules / mongodb / node_modules / kerberos / ，而我的npm install命令以 nodejs 用户身份运行，但它仍在尝试以 root 用户身份写入 / root ！一定有什么不对劲的地方，因为 root 很好地拥有该目录的权限。

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! Something must be amiss with this, because root darn well has permissions for that directory.

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

起初，我以为我只需要修正权限在 / home / nodejs 目录中，但是我认为这将对node-gyp开发人员进行跟进。

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.

至少这解释了为什么如果我以其他用户（具有sudo权限）裸奔运行npm-install命令的原因。

At least this explains why if I run the npm-install command bare as a different user (who has sudo permissions) it works.

更新： 我最终通过让npm安装程序以root身份运行，然后 chown 'ing和 chmod 来解决此问题。正在安装的文件。我用于此操作的Chef资源块如下所示：

Update: I eventually worked around this by letting the npm install run as root and then chown'ing and chmod'ing the installed files. The Chef resource blocks I used for this look something like this:

  # 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

这不能解决node-gyp在权限部门的缺点，如果在这方面得到直接答复，我将继续寻求并发布另一个答案。

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.

这篇关于挂在npm上的Chef客户端挂载在node-gyp重建上的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！