So if I run this simple call in node.js v0.6.7 on OS X 10.6.8 with a bogus path, I get an error, as expected.
var fs = require("fs");
fs.stat("/tmp/foo", function(error, stat) {
return console.log(error);
});
It prints this output:
{ [Error: ENOENT, no such file or directory '/tmp/foo'] errno: 34, code: 'ENOENT', path: '/tmp/foo' }
My question is, according to /usr/include/sys/errno.h on my system, ENOENT should have code 2, so why is this error saying errno 34 (ERANGE in errno.h), but pairing it with the error message from ENOENT?
node.js translates system errnos to internal "errnos" (see deps/uv/include/uv.h and uv_translate_sys_error in deps/uv/src/unix/error.c or deps/uv/src/win/error.c for a mapping) as to achieve a common representation for error-conditions under Windows and Unix.
34 is the node.js-errno for ENOENT, so everything is alright.
It seems that node.js changed the errno with 0.12.0. ENOENT is -2now.
So it is probably better to check for code === 'ENOENT'
because you haven't created the folder /tmp/foo yet and it's looking for that folder
(when i added a few error handling lines to my code, the console spat out the same error code and it was because i had not yet created the directory i was telling it to save my images to)
Related
I recently upgraded by version of nodejs on my windows azure web application from 0.12.0 to 0.12.6. Since then, whenever I relaunch my app on visual studio online editor, the console reports a significant errors like these ones:
glob error { [Error: ENOTSUP, scandir 'D:\home\site\wwwroot\views\partials\recommendationModal.handlebars']
errno: -4049,
code: 'ENOTSUP',
path: 'D:\\home\\site\\wwwroot\\views\\partials\\recommendationModal.handlebars' }
glob error { [Error: ENOTSUP, scandir 'D:\home\site\wwwroot\views\partials\register.handlebars']
errno: -4049,
code: 'ENOTSUP',
path: 'D:\\home\\site\\wwwroot\\views\\partials\\register.handlebars' }
glob error { [Error: ENOTSUP, scandir 'D:\home\site\wwwroot\views\partials\search.handlebars']
errno: -4049,
code: 'ENOTSUP',
path: 'D:\\home\\site\\wwwroot\\views\\partials\\search.handlebars' }
glob error { [Error: ENOTSUP, scandir 'D:\home\site\wwwroot\views\partials\spinningWheel.handlebars']
errno: -4049,
code: 'ENOTSUP',
path: 'D:\\home\\site\\wwwroot\\views\\partials\\spinningWheel.handlebars' }
glob error { [Error: ENOTSUP, scandir 'D:\home\site\wwwroot\views\partials\stylesFilterButtons.handlebars']
errno: -4049,
code: 'ENOTSUP',
path: 'D:\\home\\site\\wwwroot\\views\\partials\\stylesFilterButtons.handlebars' }
All of the files in the error descriptions are handlebars partials.
I run the same app on my local development environment (linux with nodejs 0.12.6) and these errors never show up.
At first glance, it looks like there is something broken on azure websites when running your app on 0.12.6, but I'd like to post this situation here in SO to see if other people have faced the same issue and how they managed to resolve it.
This very much looks like this bug. Sounds like you may have glob 5.0.13 or earlier installed. Try 5.0.14 and it will hopefully solve your problem.
Just had the same issue with Azure. Mine happened to be glob as one comment stated.
express-handlebars has fixed this issue if you update to 3.0.0
I am running a node scheduler using agenda. It runs fine for around 30 minutes and then it starts displaying this error.
{ [Error: EMFILE, open 'log/scheduler.log'] errno: 20, code: 'EMFILE', path: 'log/scheduler.log' }
{ [Error: EMFILE, open 'log/scheduler.log'] errno: 20, code: 'EMFILE', path: 'log/scheduler.log' }
[Error: failed to connect to [localhost:27017]]
[Error: failed to connect to [localhost:27017]]
[Error: failed to connect to [localhost:27017]]
[Error: failed to connect to [localhost:27017]]
[Error: failed to connect to [localhost:27017]]
I am using node js with mongo db deployed on a EC2 instance.
The code I wrote is here:
https://github.com/kelvinblade/bluesky-scheduler2
Any help would be appreciated.
EMFILE occurs when too many file descriptors are open as there is limitation in an os for the number of descriptors to be opened by a process.
You can reset this restriction by editing this file
/etc/sysctl.conf
or a more graceful approach is to use some module that would take care and have a connectionpool to monitor over the opened file descriptors.
You may try node-graceful-fs or filequeue
Git source :
https://github.com/isaacs/node-graceful-fs
https://github.com/treygriffith/filequeue.git
Install apppropriate node modules by
npm install node-graceful-fs
or
npm install filequeue
and replace your fs from default to
var fs = require('graceful-fs')
or
var fs = new FileQueue(100);
Personally i feel filequeue is better queuing system.
When I run jsonplaceholder I get:
jsonplaceholder
JSONPlaceholder listening on http://localhost:3000
fs.js:432
return binding.open(pathModule._makeLong(path), stringToFlags(flags), mode);
^
Error: ENOENT, no such file or directory 'data.json'
at Object.fs.openSync (fs.js:432:18)
at Object.fs.readFileSync (fs.js:286:15)
at Object.index.load (/usr/local/lib/node_modules/jsonplaceholder/node_modules/json-server/node_modules/lowdb/node_modules/underscore.db/src/node.js:11:24)
at Function.low.load (/usr/local/lib/node_modules/jsonplaceholder/node_modules/json-server/node_modules/lowdb/lib/index.js:110:29)
at reset (/usr/local/lib/node_modules/jsonplaceholder/index.js:6:14)
at Server.<anonymous> (/usr/local/lib/node_modules/jsonplaceholder/index.js:14:3)
at Server.g (events.js:180:16)
at Server.EventEmitter.emit (events.js:92:17)
at net.js:1052:10
at process._tickCallback (node.js:415:13)
Im on Ubuntu 13.10
Project's author here. Just to let you know, finally, this (old) bug was fixed. Sorry for the inconvenience caused.
I'm still not sure if this has anything to do with an outdated module, or a messed up npm installation or maybe I'm just lucky, but basically the problem is that the path to access "data.json" is wrong (maybe not wrong but incomplete).
What I did was open file:
gksudo gedit /usr/local/lib/node_modules/jsonplaceholder/index.js
and modify the following function:
function reset() {
// server.low.load('data.json') <-- ORIGINAL LINE
server.low.load(require('path').resolve(__dirname, 'data.json')); //<--MY FIX
}
Just save the file, and run jsonplaceholder again.
I'm trying to connect to multiple hosts in succession, this is the code to resolve the ip address and socket.connect() to each domain name (line[1]). This works on it's own but returns an errno 37 error when run in quick succession with different hosts. The best information I have on the error is:
" code: 'EPROTO', description: 'protocol error' "
Code:
$.connect(port, line[1], function() {
this.write(request);
});
Error:
{ [Error: connect Unknown system errno 37]
code: 'Unknown system errno 37',
errno: 'Unknown system errno 37',
syscall: 'connect' }
How can I resolve this / why is this happening?
Thanks in advance.
EDIT: removed manual dns lookup code and added error report
duplicate with https://stackoverflow.com/questions/14672743/nodejs-crash-when-calling-socket-connect-in-quick-succession
Seems to me opening sockets in rapid succession is asking for trouble.
Try waiting in between opening the sockets and play with the amount of time needed to wait.
What can be the reason for a Linux socket to set the error to ENOENT on readv() ?
The socket in question is non-blocking and runs on Ubuntu 10.04
errno is only set when a system call returns -1. You should only read it after checking the return value of readv.