EMBER_CLI_PROD_ASSETS to 1 crashes precompiling assets

Comes from New installs will default to Ember CLI builds in Production - #36 by david

Hi Team,

While trying setting EMBER_CLI_PROD_ASSETS to 1, I’m getting the following at the time of precompiling assets (version 2.9.0.beta2 commit: d2de058ff51f204fcf85c86a00750a59505af3bb):

yarn run v1.22.17
$ /var/www/discourse/app/assets/javascripts/node_modules/.bin/ember build -prod
WARNING: Node v16.13.2 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js. See https://git.io/v7S5n for details.
DEPRECATION: The integration of jQuery into Ember has been deprecated and will be removed with Ember 4.0. You can either opt-out of using jQuery, or install the `@ember/jquery` addon to provide the jQuery integration. Please consult the deprecation guide for further details: https://emberjs.com/deprecations/v3.x#toc_jquery-apis
A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)

node:internal/errors:464
    ErrorCaptureStackTrace(err);
    ^

SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)
    at new SystemError (node:internal/errors:233:5)
    at new NodeError (node:internal/errors:336:7)
    at Object.userInfo (node:os:347:11)
    at summarizeProcess (/var/www/discourse/app/assets/javascripts/node_modules/console-ui/lib/summarize-process.js:17:15)
    at writeError (/var/www/discourse/app/assets/javascripts/node_modules/console-ui/lib/write-error.js:114:3)
    at UI.writeError (/var/www/discourse/app/assets/javascripts/node_modules/console-ui/lib/index.js:167:20)
    at CLI.logError (/var/www/discourse/app/assets/javascripts/node_modules/ember-cli/lib/cli/cli.js:318:13)
    at CLI.run (/var/www/discourse/app/assets/javascripts/node_modules/ember-cli/lib/cli/cli.js:253:12)
    at processTicksAndRejections (node:internal/process/task_queues:96:5)
    at async module.exports (/var/www/discourse/app/assets/javascripts/node_modules/ember-cli/lib/cli/index.js:145:12) {
  code: 'ERR_SYSTEM_ERROR',
  info: {
    errno: -2,
    code: 'ENOENT',
    message: 'no such file or directory',
    syscall: 'uv_os_get_passwd'
  },
  errno: [Getter/Setter],
  syscall: [Getter/Setter]
}
error Command failed with exit code 1.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.

Any hint about why this is happening?

Cheers,
Ismael

1 Like

Is that a production install using the install guide?

Can you try a rebuild?

1 Like

No success after a rebuild of the instance. I’m more looking for what is causing the uv_os_get_passwd call, or more generally about what is causing this error, does this expect any specific user in the system/setting to be set?

Cheers,
Ismael

How exactly are you running the Discourse image? Are there any extra flags for security?

Following this trace, the problem is that the Ember-CLI build is failing, and while trying to print the error, it is throwing yet another exception and masking the real one.

Can you go inside the Discourse image and try:

node
const os = require('os');
os.userInfo().shell

?

1 Like

Intersting, this is what I’m getting when executing your suggestion (and makes total sense if the intention is to access any internal library system with a random user other than root):

node
Welcome to Node.js v16.13.2.
Type ".help" for more information.
> const os = require('os');
undefined
> os.userInfo().shell
Uncaught:
SystemError [ERR_SYSTEM_ERROR]: A system error occurred: uv_os_get_passwd returned ENOENT (no such file or directory)
    at __node_internal_captureLargerStackTrace (node:internal/errors:464:5)
    at new SystemError (node:internal/errors:233:5)
    at new NodeError (node:internal/errors:336:7)
    at Object.userInfo (node:os:347:11) {
  code: 'ERR_SYSTEM_ERROR',
  info: {
    errno: -2,
    code: 'ENOENT',
    message: 'no such file or directory',
    syscall: 'uv_os_get_passwd'
  },
  errno: [Getter/Setter: -2],
  syscall: [Getter/Setter: 'uv_os_get_passwd']
}
>

How exactly are you running the Discourse image? Are there any extra flags for security?

We’ve been using a containerized solution based in OpenShift, in which Discourse is running with a random user id. No issues so far, approach very similar to the official install guide.
It’s certainly that we can bypass this issue by setting EMBER_CLI_PROD_ASSETS to 0, assets are precompiled as in the old days, but sooner than later, if your plans are to move into this direction, can pose a real problem for this kind of solutions if the current precompiling process is abandoned.

So a couple of questions here:

  • Do you have an ETA about abandoning (if that’s the case) precompiling assets the old way?
  • Is there any way to access the os machinery on a different way, or consider a different approach, so that containerized solutions with random user id’s can still work?

Many thanks for looking into this, much appreciated.

Cheers,
Ismael

1 Like

We are removing that EMBER_CLI_PROD_ASSETS in the next few weeks.

We are not using that directly, but a dependency, of a dependency, of a depedency… I think it’s a weird call too, but it’s not something we have much control over.

1 Like

Note that the error you are seeing is not the actual error.
It’s an error that happens when trying to show you the real error…

3 Likes

It is exactly the same issue as in Issue with non 'username' defined · Issue #2373 · nodejs/node-gyp · GitHub and os.userInfo throws if no username in docker container · Issue #25714 · nodejs/node · GitHub

By using a random user id, node complains at the time of loading os system-related utility methods and properties.

Just to confirm, old way will be totally deprecated/removed, right?

Cheers,
Ismael

1 Like

Yep, understood after the post above. Unless Team does any special action/checks to allow this, the era of using random user id’s is over imho.

Cheers,
Ismael

1 Like

Yes, exactly. We’ve been slowly releasing this new asset pipeline over years, so we can track what the EmberJS project recommends and be less of a snowflake. We are in the final phase of the rollout already.

2 Likes

Excellent, all clear.

As usual, many thanks for your detailed info, much appreciated.

Cheers,
Ismael

1 Like

Just for the record, and whether it is useful for somebody around. There is at least a way to make ember cli working as expected with a random uid, and it is ensuring that the assigned random uid has an entry under /etc/passwd at the time of running the rake assets:precompile operation.

Something like:

if [ `id -u` -ge 10000 ]; then
  cat /etc/passwd | sed -e "s/^discourse:/builder:/" > /tmp/passwd
  echo "discourse:x:`id -u`:`id -g`:,,,:/home/discourse:/bin/bash" >> /tmp/passwd
  cat /tmp/passwd > /etc/passwd
  rm /tmp/passwd
fi

Thus, app/assets/javascripts/discourse run ember build -prod command (from discourse/assets.rake at tests-passed · discourse/discourse · GitHub) will make it.

yarn run v1.22.17
$ /discourse/app/assets/javascripts/node_modules/.bin/ember build -prod
WARNING: Node v16.13.2 is not tested against Ember CLI on your platform. We recommend that you use the most-recent "Active LTS" version of Node.js. See https://git.io/v7S5n  for details.
DEPRECATION: The integration of jQuery into Ember has been deprecated and will be removed with Ember 4.0. You can either opt-out of using jQuery, or install the `@ember/jquery` addon to provide the jQuery integration. Please consult the deprecation guide for further details: https://emberjs.com/deprecations/v3.x#toc_jquery-apis 
- Building
Environment: production
- Building
- building... 
[WARN] (broccoli-terser-sourcemap) Minifying "assets/chunk.529.6ee9018498e97f872147.js" took: 24288ms (more than 20,000ms)
...

I have also noticed that this operation is quite expensive, by consuming almost 2GB of ram just for precompiling :scream:

Cheers,
Ismael

2 Likes

It was using over 4GB last week, but we managed to make it work on 1GB RAM/2GB swap servers recently.

4 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.