I am using A2Hosting vendor to deploy my Next js app as a server. I have written all the scripts and tested on my local machine, but when I deploy it to the webserver and run
npm run build this is what happens:
throw errnoException(err, 'spawn'); ^
Error: spawn ENOMEM
at ChildProcess.spawn (internal/child_process.js:394:11)
at spawn (child_process.js:540:9)
at Object.fork (child_process.js:108:10)
at ChildProcessWorker.initialize (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/jest-worker/build/workers/ChildProcessWorker.js:137:44)
at new ChildProcessWorker (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/jest-worker/build/workers/ChildProcessWorker.js:127:10)
at WorkerPool.createWorker (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/jest-worker/build/WorkerPool.js:44:12)
at new BaseWorkerPool (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/jest-worker/build/base/BaseWorkerPool.js:82:27)
at new WorkerPool (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/jest-worker/build/WorkerPool.js:30:1)
at new JestWorker (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/jest-worker/build/index.js:131:26)
at TaskRunner.run (/home/briddgyc/nodevenv/Br-Front/12/lib/node_modules/next/dist/build/webpack/plugins/terser-webpack-plugin/src/TaskRunner.js:3:202) {
errno: 'ENOMEM',
code: 'ENOMEM',
syscall: 'spawn'
}
I have checked that this is some kind of memory issue but 2 days and still cannot figure out anything.
I have still 40 Process and 700mb of RAM in my machine it should be sufficient I suppose.
Any recommendations ?
I have received a reply from support saying that the only way is to compile locally.
The process took more than 110% of CPU and reached 50/50 maxing the number of processes, and I'm still halfway through the project. Adding more commands that might even require more resources for compilation later on, I would rather stay safe and locally compile.
Related
TL;DR: I got an spawn ENOMEM error when trying to build and run my Next.js app on a shared hosting server, which had over 900MB RAM and 70+ processes available at the time this happened. The log showed that the RSS size was 50814976 when the error was caught.
I am not quite sure if the error is simply caused by insufficient memory or it occurs because of incorrect settings or configs. Could you please give me some advice?
==========Details below============
I am building a Next.js app with Node.js, and it’s built with a custom server (my entry point: server.js). I can run my app in a local environment on localhost:3000. Then I try deploying it to check if it’s ok on the network.
I have subscribed to A2 Hosting’s DRIVE Web Shared Hosting Plan, which is optimised to support Node.js environment. What they offer in the plan are 1GB of physical memory and 75 available processes.
My application was created through the Setup Node.js App function on the cPanel, and cloned my project into the server with git via SSH. NPM packages were also installed on the server with the command npm install. The node version was v.12.9.1 and npm version was 6.14.8.
My npm scripts were defined to run the custom server. Here were the npm scripts defined in my package.json file:
"scripts": {
"dev": "node server.js"
"build": "next build",
"start": "NODE_ENV=production node server.js"
}
Then I used the command npm run build to create the production application in the .next folder, but an error spawn ENOMEM came up immediately.
I googled that it was a memory usage related issue. Some said this error occurred when memory was not enough, and the workaround to bypass this was to build the production folder locally and upload it to the server. So I copied the steps.
However, the result was frustrating when I ran the command npm run start. The error ENOMEM was still here, coming up in less than a second after I entered the command.
Cleaning the npm cache and reinstalling the npm modules didn’t seem to work either.
I tried increasing the memory limit by adding option --max-old-space-size in the command and ran NODE_ENV=production node --max-old-space-size=1024 server.js; but unfortunately this didn’t seem to work and the ENOMEM still popped up.
I added console.log(process.memoryUsage()) to show the usage when an error was caught and this was the result:
{
rss: 50814976,
heapTotal: 34107392,
heapUsed: 23076064,
external: 1632450
}
The total rss size was far less than the limit. Or did I use a wrong method to inspect the memory consumption?
How can I solve the ENOMEM problem? What exactly the error is caused by? Is it really just because the available RAM doesn't meet the requirement of a next.js app?
I am not sure if I have applied incorrect settings, overlooked some important configs, or miswritten any codes that bring about this error. I want to figure out what is going on underneath. Upgrading the plan impulsively without adequate understanding isn’t good for me as a newbie developer, and it's my responsibility to make good use of the budget.
Could you please give me some advice?
Thank you for your attention.
I have a firebase project I've been maintaining for months and haven't had any problems with.
I've tried running firebase deploy multiple times to no avail. I've googled it and searched on SO, github, and others, found these links, none of which worked. I've tried updating firebase tools, uninstalling and reinstalling, and everything between. Please don't blindly flag as duplicate without reading.
The first line of my error looks like this:
\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\lib\winston\logger.js:307
throw ex;
Here's my full output:
firebase deploy
C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\lib\winston\logger.js:307
throw ex;
^
Error: write after end
at writeAfterEnd (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_writable.js:261:12)
at PassThrough.Writable.write (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_writable.js:305:21)
at File.log (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\lib\winston\transports\file.js:185:34)
at File._write (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston-transport\index.js:103:17)
at doWrite (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\readable-stream\lib_stream_writable.js:428:64)
at writeOrBuffer (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\readable-stream\lib_stream_writable.js:417:5)
at File.Writable.write (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\readable-stream\lib_stream_writable.js:334:11)
at DerivedLogger.ondata (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_readable.js:681:20)
at DerivedLogger.emit (events.js:203:15)
at DerivedLogger.EventEmitter.emit (domain.js:448:20)
at addChunk (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_readable.js:298:12)
at readableAddChunk (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_readable.js:280:11)
at DerivedLogger.Readable.push (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_readable.js:241:10)
at DerivedLogger.Transform.push (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_transform.js:139:32)
at DerivedLogger._transform (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\lib\winston\logger.js:305:12)
at DerivedLogger.Transform._read (C:\Users\justi\AppData\Roaming\npm\node_modules\firebase-tools\node_modules\winston\node_modules\readable-stream\lib_stream_transform.js:177:10)
I'm completely stuck on this, I've been searching for an hour, and I've never had this fail for me before, so I don't know what's going on with firebase. Thanks in advance.
For others that come this way, I had this exact error message and stack trace. I was attempting to run firebase deploy --except functions while following this code lab step.
For me the fix was simply to stop serving the firebase app locally for debug.
Once I had done this, no reboot, just back in the other terminal and submit the deploy command and it worked fine.
The code lab gets you to do this and then leave it served locally while changing various parts of the app, but I have no idea what caused winston to conflict this way.
This probably an issue with NPM try running npm cache clean and reinstall firebase tools. If that didn't work try contacting firebase support. Recently I ran into an issue with firebase hosting and they were really helpful but took about 30 hours for their response after making the support ticket.
I had the exact same error, I tried restarting Command Prompt, deleting the cache file in the .firebase project folder. deploy worked fine with a separate test project.
On a whim I shut down my local server, and firebase deploy worked fine. Not sure if that's the real fix, as I'm 99.9% sure I did deploys in the past with the local server running... but it works for me now.
And after deploy was working again, it stopped a second time with the same error. So I stopped the server, and once again deploy worked. Then if failed a third time, same fix, shut down the local server.
Local server was run via firebase serve --only hosting
npm cache verify also checked out A-OK:
https://docs.npmjs.com/cli-commands/cache.html
I do not know, if this is related to koa, or is problem of some other npm module or something else. I am going to start from here.
So to the problem. I am having REST api written in koa v1. We are running node server in the Docker image. One of the endpoints we have, starts the import and returns the status 200 with message: "import started", and when the import finishes, we send Slack message to notify us.
So first I tested the server on my local machine, everything works (endpoint does not throw any errors). Then I built docker image. I run container localy, everything works (endpoint does not throw any errors). I deploy my image to Mesos environment, everything works so far. Container runs, every endpoint works, beside import endpoint. When I call it, after few seconds (5 to 10), I get ECONNRESET error, the running container gets killed and new running instance is started. So import is terminated.
At the beginning we assigned 128 MB ram to the docker container and that seems to be enough. After import error occurred, we thought maybe OOM killed process. So we decided to check dmesg and we could not find any log entries related to the OOM and the process of the running container. Then we checked ram usage of the container locally (with htop) and found out it uses aprox. 250+ MB, so we decided to add more ram in marathon config (512 MB). That however did not help, same error occurred.
Because the error was not explicit enough we installed longjohn module, so we could get more detailed error message. That got us just a little bit more information, but not as much as we thought it would.
Error: read ECONNRESET
at exports._errnoException (util.js:1026:11)
at TCP.onread (net.js:569:26)
---------------------------------------------
at Application.app.callback (/src/node_modules/koa/lib/application.js:130:45)
at Application.app.listen (/src/node_modules/koa/lib/application.js:73:39)
at Promise.then.result (/src/server.js:97:13)
Error: read ECONNRESET
at exports._errnoException (util.js:1026:11)
at TCP.onread (net.js:569:26)
Line 97 of the server.js is:
96:if(!module.parent) {
97: app.listen(port, (err) => {
98: if (err) {
99: console.error('Server error', err);
100: }
101: console.log('Listening on the port', port);
102: });
103:}
So what exactly happens in the endpoint logic. We are using postgres npm module pg. We are passing pg.Pool to the context, so later we can use it in our models. We are executing insert query encapsulated in promise and push promises in the array. There are roughly 2700+ records. Later we do Promise.all on the array of promises and with then we send the message to Slack.
As you can see I do not know if the error is related to koa or pg or some other thing. What is more intriguing is that locally everything works (node server as well as in docker container), but on Mesos it does not. How can I find out what is wrong?
version of koa npm module: 1.2.0
version of pg npm module: 6.1.0
version of Postgres 9.5
version of Mesos: 1.0.1
According to this github issue this is an error caused by tiny-lr.
It seems that downgrading to version 0.2.1 stops it, but this is usually a dependency of other packages you're using that you've got no control over. You might be able to filter out the error by displaying all errors except this, as such:
if (error.code !== 'ECONNRESET') { console.log(error) }
The issue is still open, and dates from Oct 27, 2016. Don't know if it will get fixed or not. But as far as feedback goes, it doesn't seem like a dangerous error, or to have any impact whatsoever. But heh, I'd rather fix mine too, if there was a way.
Thanks to another developer, we found out what was the cause of the ERROR. We used all connections in the pool when there was an import running.
When the marathon was requesting the service status at the time of the import, service tried to connect to the database to test the connection and at that time the connection to the database was terminated. Service became unhealthy and marathon restarted the service. We re-factored the import code. We are limiting the number of pool connections.
I'm trying to put my app into production with Sails.js, but cannot get past the grunt tasks. This is the error I'm receiving:
error: Error: The hook `grunt` is taking too long to load.
Make sure it is triggering its `initialize()` callback, or else set
`sails.config.grunt._hookTimeout to a higher value (currently 20000)
at tooLong [as _onTimeout]
(/usr/local/lib/node_modules/sails/lib/app/private/loadHooks.js:92:21)
at Timer.listOnTimeout (timers.js:110:15)
I have increased sails.config.grunt._hookTimeout dramatically and still the process hasn't been completed. Running a sails debug in either production or development outputs:
Grunt :: Error: listen EADDRINUSE
at exports._errnoException (util.js:746:11)
at Agent.Server._listen2 (net.js:1156:14)
at listen (net.js:1182:10)
at Agent.Server.listen (net.js:1267:5)
at Object.start (_debugger_agent.js:20:9)
at startup (node.js:86:9)
at node.js:814:3
I find it very strange that in development mode everything works fine, but its not the case in production. The files included are pretty big, such as angular, moment and other modules. This is how the jsFilesToInject looks:
var jsFilesToInject = [
// Load sails.io before everything else
'js/dependencies/sails.io.js',
'js/dependencies/angular.min.js',
'js/dependencies/moment.min.js',
'js/dependencies/angular-ui-router.min.js',
'js/dependencies/angular-sails.min.js',
'js/dependencies/angular-moment.min.js',
'js/dependencies/angular-animate.min.js',
'js/dependencies/angular-aria.min.js',
'js/dependencies/angular-material.min.js',
// All of the rest of your client-side js files
// will be injected here in no particular order.
'js/**/*.js'
];
I'm not sure what else would be causing this, any suggestions? I'm using Sails version 0.11.0
I just had this same problem and it was just that the timeout was not big enough I had to put this in my config/local.js file:
module.exports = {
hookTimeout: 120000
};
I just posted the same issue on github, and then checked out the source code. So I read through the grunt hook to understand what happens. And it turns out that in default mode the grunt hook triggers the callback right after grunt has started, but for the prod mode it is triggered only when grunt has finished all the tasks.
There is a following comment in the source code:
cb - optional, fires when the Grunt task has been started (non-production) or finished (production)
So if there is anything watching (like using watch in browserify) in prod, grunt task will never exit, and therefore grunt hook will always timeout. But even if nothing is watching, starting the grunt task takes much longer that finishing all the tasks, and this explains why we don't see the problem when not in production mode.
Since modifying the original grunt hook is not the best idea (it lives in node_modules), the best is indeed to increase (possibly dramatically) the _hookTimeout option and to make sure grunt task exits (for this it can be run separately with grunt prod).
I downloaded node.js (.3), redis (2.0.4), and redis-node-client (git clone). When I start the redis server in one window, then go to the node-client folder and run
node test/test.js
I get
........................................
node.js:66
throw e; // process.nextTick error, or 'error' event on first tick
^
Maximum call stack size exceeded
I'm using the default configs at the moment. Haven't changed anything. Any ideas?
Hm, turns out to be version incompatibilities. Going to v0.2.5 fixes it.
Edit: nevermind, no it doesn't. Comes up with new error:
AssertionError: "testZINTER" "ERR unknown command 'zinter'"
at /Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/test/test.js:121:25
at Client.onReply_ (/Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:400:34)
at /Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:143:30
at ReplyParser.feed (/Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:160:55)
at Stream.<anonymous> (/Users/vhwanger/Dropbox/Programming/nodejs/redis-node-client/lib/redis-client.js:337:28)
at Stream.emit (events:27:15)
at IOWatcher.callback (net:489:16)
at node.js:773:9
Sadly, redis-node-client is no longer maintained. That's why I've written node_redis, which you can get with:
npm install redis
There are a lot of people using it now, and this has helped us work out a lot of bugs. Let me know if you have any issues with it.