Error: nodent-runtime@3.2.1 install: `node build.js`

0

Hi. I'm having trouble deploying a node.js app via Elastic Beanstalk, and now also via Code Pipeline (on the deploy step). I've tried deploying both using node 8.16.0 and 10.16. It appears to be a problem with nodent, which I think polyfills in async support for es7.

When I SSH into the EB created EC2 host directly, set the PATH to include node, I can run "npm --production install" and it builds and runs the express app, no problem.

However, installing both via 'eb deploy' and Code Pipeline each fail with the same error listed in the subject of this message.

Here are the relevant lines from the log file on the EC2 instance from "/tmp/.npm/logs":

394 verbose lifecycle nodent-runtime@3.2.1~install: CWD: /tmp/deployment/application/node_modules/nodent-runtime
395 silly lifecycle nodent-runtime@3.2.1~install: Args: [ '-c', 'node build.js' ]
396 silly lifecycle nodent-runtime@3.2.1~install: Returned: code: 1  signal: null
397 info lifecycle nodent-runtime@3.2.1~install: Failed to exec install script
398 verbose stack Error: nodent-runtime@3.2.1 install: `node build.js`
398 verbose stack Exit status 1
398 verbose stack     at EventEmitter.<anonymous> (/opt/elasticbeanstalk/node-install/node-v10.16.0-linux-x64/lib/node_modules/npm/node_modules/npm-lif
ecycle/index.js:301:16)
398 verbose stack     at EventEmitter.emit (events.js:198:13)
398 verbose stack     at ChildProcess.<anonymous> (/opt/elasticbeanstalk/node-install/node-v10.16.0-linux-x64/lib/node_modules/npm/node_modules/npm-lif
ecycle/lib/spawn.js:55:14)
398 verbose stack     at ChildProcess.emit (events.js:198:13)
398 verbose stack     at maybeClose (internal/child_process.js:982:16)
398 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
399 verbose pkgid nodent-runtime@3.2.1
400 verbose cwd /tmp/deployment/application
401 verbose Linux 4.14.123-86.109.amzn1.x86_64
402 verbose argv "/opt/elasticbeanstalk/node-install/node-v10.16.0-linux-x64/bin/node" "/opt/elasticbeanstalk/node-install/node-v10.16.0-linux-x64/bin/
npm" "--production" "rebuild"
403 verbose node v10.16.0
404 verbose npm  v6.9.0
405 error code ELIFECYCLE
406 error errno 1
407 error nodent-runtime@3.2.1 install: `node build.js`
407 error Exit status 1
408 error Failed at the nodent-runtime@3.2.1 install script.
408 error This is probably not a problem with npm. There is likely additional logging output above.
409 verbose exit [ 1, true ]

Here is my package.json

{
  "name": "gopostal",
  "version": "1.0.0",
  "description": "GoPostal: Clio Manage & EasyPost",
  "private": true,
  "main": "server.js",
  "scripts": {
    "start": "node ./server.js"
  },
  "repository": {
    "type": "git",
    "url": "git+ssh://git@github.com/vann/gopostal.git"
  },
  "author": "vann miller",
  "license": "ISC",
  "bugs": {
    "url": "https://github.com/vann/gopostal/issues"
  },
  "homepage": "https://github.com/vann/gopostal#readme",
  "dependencies": {
    "@easypost/api": "^3.7.0",
    "JSV": "4.0.x",
    "aws-sdk": "^2.482.4",
    "axios": "^0.19.0",
    "bcryptjs": "^2.4.3",
    "client-oauth2": "^4.2.4",
    "connect-flash": "^0.1.1",
    "constantinople": "^3.1.1",
    "cookie-parser": "^1.4.3",
    "cookie-session": "1.3.3",
    "crypto-js": "^3.1.9-1",
    "debug": "4.1.1",
    "ejs": "^2.6.1",
    "engine.io": "^3.2.0",
    "engine.io-client": "^3.2.1",
    "express": "~4.17.0",
    "express-session": "^1.15.6",
    "http": "0.0.0",
    "http-errors": "~1.7.2",
    "human-readable-ids": "^1.0.4",
    "i18n-iso-countries": "^4.1.1",
    "keygrip": "^1.0.2",
    "moment": "^2.18.1",
    "mongodb": "3.2.x",
    "mongoose": "^5.6.1",
    "morgan": "~1.9.0",
    "nodent": "^3.2.11",
    "passport": "~0.4.0",
    "passport-local": "~1.0.0",
    "pug": "^2.0.4",
    "request": "^2.88.0",
    "request-promise": "^4.2.4"
  },
  "devDependencies": {
    "mocha": "^6.1.4"
  }
}

And buildspec.yml:

version: 0.2
phases:
  pre_build:
    commands:
      - npm install
  install:
    runtime-versions:
      nodejs: 10
  build:
    commands:
      -
artifacts:
  files:
    - '**/*'

Any insight welcome. Thanks all.

Edited by: V. Miller on Jun 28, 2019 1:37 PM

asked 5 years ago464 views
3 Answers
0

I'm thinking it might be a permission issue. This is because the command that fails uses a CWD for a subdirectory of node_modules/ that's only root writeable:

[root@ip-10-0-0-227 dist]# pwd -P
/tmp/deployment/application/node_modules/nodent-runtime/dist
[root@ip-10-0-0-227 dist]# ls -la
total 20
drwxr-xr-x 2 root root 4096 Jun 28 20:59 .
drwxr-xr-x 4 root root 4096 Jun 28 20:59 ..
-rw-r--r-- 1 root root 6294 Jun 28 20:58 index.js
-rw-r--r-- 1 root root  455 Nov 16  2017 README.md

Also, while it fails when run via EB, it works just fine when I run it on the EC2 instance myself.

What I do is I set the $PATH to include node as before, change the working dir to:

/tmp/deployment/application/node_modules/nodent-runtime

and then run "node build.js" .

It creates the "./dist/index.js" file with no errors inside of "node_modules/nodent-runtime/dist" ..again, this is only writeable by root.

I'm not sure if EB logins to the EC2 instance using root; tailing /var/log/secure doesn't say.

I may have to use some eb config file to set that node directory to world writeable, or owned by whatever user is used to deploy, before this build step runs, I'm thinking. Any hints on that?

Edited by: V. Miller on Jun 28, 2019 2:11 PM

answered 5 years ago
0

I've tried using an .ebextension config file to set the directory permisssion, but I suspect the command runs at the wrong time. At least, it doesn't solve the issue.

container_commands:
    01_change_permissions:
        command: chmod 777 /tmp/deployment/application/node_modules/nodent-runtime/dist

It may also be a red herring, as that directory is recreated, along with the index.js file, after each deploy. Which begs the question why build.js reports that it's failing, unless it's trying to overwrite the file and failing.

Still at a loss.

answered 5 years ago
0

That should've been "commands", not "container_commands".

It was indeed a permissions issue, but various tactics of setting the /temp/ directory owner or permissions did not help. However, I was finally able to address the issue by creating a .npmrc file with these contents:

unsafe-perm=true
answered 5 years ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions