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).
Related
I'm building an E-commerce site, where there's an Authentication system.
I noticed that if the client login with a wrong user or password, the backend/server that works with nodemon will crach and hang in there crashed till i restart manually nodemon. This is example output error of the nodemon crash:
[nodemon] app crashed - waiting for file changes before starting...
node:internal/errors:464
ErrorCaptureStackTrace(err);
^
Error [ERR_HTTP_HEADERS_SENT]: Cannot set headers after they are sent
to the client
Ofcourse, when server crashes, client can no more access or do login again till server restarts.
After some googling, i found this question and this repository that fix my problem but particulary and not as expected precisely, i dont want nodemon to restart forever on any error that occure ofcourse, but only with specifics errors that i set them -like Authentication errors as i mentionned above-.
So, my idea/question is: is there anyway to get nodemon restarts by itself in some cases of failures or errors (NOT ALL)?
Seems like you a referring to a production situation, and nodemon is a development node server, which is not intended for use in production, as the intro states:
nodemon is a tool that helps develop Node.js based applications by
automatically restarting the node application when file changes in the
directory are detected.
You should use node.js in production, instead of nodemon.
For managing your node server in production, you could use a process manager like PM2..
That said, an authentication server that crashes every time a user uses a wrong password seams very ineffective in handling a common use case. So I would advise to start with fixing the root cause, which is the buggy server, and then for recovery from incidental crashes use something like PM2.
PS:
The error you are getting looks like an express error you get when you send a response (in this case an error response) without exiting the function e.g. by using return. Because you are not returning, another res.send is called, which causes the 'ERR_HTTP_HEADERS_SENT' error. See this answer.
This is really bad since it can send your program into a loop of restarting, but if you really want it, replace app.js with your file's name and try this:
nodemon -x 'node app.js || copy /b app.js +,,'
Linux version:
nodemon -x 'node app.js || touch app.js'
Next time try a little googleing before you ask since it is most likely faster.
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.
I want to run the exact same grunt watch task in production mode that's run in development mode. I thought it would be as simple as adding the watch task to the "prod.js" task in tasks/register/prod.js, but doing that hangs Sails upon lift.
How do I run the watch task in production?
How do I run the watch task in production?
I have found out recently that sails (v.0.11.0) restricts grunt executions in production mode before startup. To fix this problem, you need to change a few lines in /node_modules/sails/lib/hooks/grunt/index.js
Specifically, comment the lines:
// Fire finish after grunt is done in production
/*if(sails.config.environment === 'production'){
cb_afterTaskStarted();
}*/
comment and add:
// Go ahead and get out of here, since Grunt might sit there backgrounded
/*if(sails.config.environment !== 'production'){
cb_afterTaskStarted();
}*/
cb_afterTaskStarted();
In the JHipster gulpfile.js, there is a watch task set up for JS files which attempts to call a 'browserify' task. However, there is no 'browserify' task defined. If you are running 'gulp server' during development, the process will terminate as soon as you modify one of your JS files.
[11:43:19] Server started
[11:43:19] LiveReload started on port 35729
[11:43:19] Finished 'server' after 52 ms
**[11:52:14] Task 'browserify' is not in your gulpfile**
[11:52:14] Please check the documentation for proper gulpfile formatting
Is this a bug? I don't see why we would need to call to browserify with the current setup.
Yes it looks like a bug:https://github.com/jhipster/generator-jhipster/issues/367
The Gulp option is a community effort, and is less stable than the Grunt option.
However, of course, our goal is to have a correct and stable Gulp option for our soon-to-be-released 1.0 version.
Can you add your comments and feedback to the opened bug?
I'm using gulp and running nodemon from a task. Everytime it detects changes it
restarts the server
runs "build" task
Yup in that order. Couldn't figure out how to kick "build" task before nodemon's restart happens (setting delay param didn't help).
nodemon = require "gulp-nodemon"
runSequence = require 'run-sequence' # couldn't figure out how to run gulp task
# from another task, so ended up using this
nodemon(
script:'server.js'
watch: 'src/**/*.*'
).on "restart" (files)->
runSequence "build"
Now, my problem is - when something happens during build, something that I apparently can't really control (let's say Jade files fail to compile), process throws uncaughtException and crashes. What I need though, to restart nodemon, and keep trying building until failing jade file fixed.
I've tried running "build", followed with nodemon in process.on 'uncaughtException', it kinda works, but then nodemon stops watching files and can't recognize changes anymore.
Can you guys advise.