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

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

Is that a production install using the install guide? Can you try a rebuild?

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 ?

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

[image] trobiyo: Do you have an ETA about abandoning (if that’s the case) precompiling assets the old way? We are removing that EMBER_CLI_PROD_ASSETS in the next few weeks. [image] trobiyo: 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? 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.

[image] trobiyo: 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 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…

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. [image] Falco: We are removing that EMBER_CLI_PROD_ASSETS in the next few weeks Just to confirm, old way will be totally deprecated/removed, right? Cheers, Ismael

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

[image] trobiyo: Just to confirm, old way will be totally deprecated/removed, right? 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.

Excellent, all clear. As usual, many thanks for your detailed info, much appreciated. Cheers, Ismael

EMBER_CLI_PROD_ASSETS to 1 crashes precompiling assets

Product Support

Falco (Falco) February 18, 2022, 5:10pm 13

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

Topic		Replies	Views
New installs will default to Ember CLI builds in Production Announcements ember	36	4500	June 17, 2022
Excessive consumption of memory due to precompiling assets Product Support unsupported-install	11	473	May 5, 2026
Clean install of discourse resulting in failure Self-hosting	8	580	February 23, 2024
New Install Bootstrap Fail in 'bundle exec rake themes:update assets:precompile' Self-hosting	7	611	February 21, 2024
Discourse Assets Missing Self-hosting unsupported-install	17	2486	February 22, 2020

EMBER_CLI_PROD_ASSETS to 1 crashes precompiling assets

Related topics