4 ms·

Getting this error: Error: ENOENT, no such file or directory '/root/apps/status/client/static/assets/main/1340976517230.html' at Object.openSync (fs.js:240

Getting this error: Error: ENOENT, no such file or directory '/root/apps/status/client/static/assets/main/1340976517230.html' at Object.openSync (fs.js:240:18) at Object.readFileSync (fs.js:128:15) at ServerResponse.<anonymous> (/root/apps/status/node_modules/socketstream/lib/client/http.js:34:26) at EventEmitter.<anonymous> (/root/apps/status/app.coffee:48:16) at EventEmitter.emit (/root/apps/status/node_modules/socketstream/node_modules/eventemitter2/lib/eventemitter2.js:319:22) at Router.route (/root/apps/status/node_modules/socketstream/lib/http/router.js:18:15) at Object.handle (/root/apps/status/node_modules/socketstream/lib/http/index.js:96:54) at next (/root/apps/status/node_modules/socketstream/node_modules/connect/lib/proto.js:190:15) at /root/apps/status/node_modules/socketstream/node_modules/connect/lib/middleware/session.js:299:9 at /root/apps/status/node_modules/socketstream/node_modules/connect/lib/middleware/session.js:322:9

anemic 14y ago
I hope the /root/ refers to the site's root directory and not root user's home directory. At least this confirms that it's actually running socketstream...
- wavephorm 14y ago
  Probably not a good idea to run NodeJS as root.
  - dedward 14y ago
    Why not... It's an age-old concept, one I've enforced over decades, but seriously..... nowadays, once you are in, you are in, and systems (at least the ones I've put together in recent yeras, I can only assume the same of others) are very regularly refreshed from scratch from servers that can't be reached from the public facing stuff. (so even if you manage to find that one old php server and find some bug and drop some php thingy on it, it's going to get squished in 30 seconds, give or take, as regular housekeeping takes place. If you managed to actually focus on the attack and go deeper, it might take longer -but root or no root, the damage you can do is the same either way, and limited hte same either way. EDIT: For the record - I still follow this practice, I'm just debating it's relevance these days. Things change, right?
owenb 14y ago
Hi carlsednaoui As the creator of SocketStream, I am very keen to know how this error occurred. I believe it relates to the ulimit issue Paul mentioned in another comment which was fixed some time ago (i.e. the file was there, but the user was out of file descriptors)... not sure yet. Either way, we need to catch the exception properly. As a general tip to all those hosting a Node app in production, you can catch uncaught exceptions with: process.on('uncaughtException', function(err) { console.log(err); }); This ensures anything which goes wrong unexpectedly will be logged to your console, rather than sent to the browser - not good! SocketStream doesn't currently do this for you by default, but maybe it should (in production mode). It's something I will consider implementing in the near future. So far my focus has been on creating a great dev environment. It's very encouraging to see Dashku stand up to thousands of simultaneous users (once the ulimit issue was fixed), but I'm the first to admit more work is needed to ensure SocketStream is rock solid in production. It will take time but, thanks in part to experiences like today's, we'll get there. Great job Paul. Owen
- zenocon 14y ago
  I'm building a fairly large app right now with SocketStream and I just want to say that it is a joy to use. It really is a great dev. environment...flexible, useful, lightweight, and intuitive even without a ton of documentation.

anemic 14y ago

I hope the /root/ refers to the site's root directory and not root user's home directory. At least this confirms that it's actually running socketstream...

wavephorm 14y ago
Probably not a good idea to run NodeJS as root.
- dedward 14y ago
  Why not... It's an age-old concept, one I've enforced over decades, but seriously..... nowadays, once you are in, you are in, and systems (at least the ones I've put together in recent yeras, I can only assume the same of others) are very regularly refreshed from scratch from servers that can't be reached from the public facing stuff. (so even if you manage to find that one old php server and find some bug and drop some php thingy on it, it's going to get squished in 30 seconds, give or take, as regular housekeeping takes place. If you managed to actually focus on the attack and go deeper, it might take longer -but root or no root, the damage you can do is the same either way, and limited hte same either way. EDIT: For the record - I still follow this practice, I'm just debating it's relevance these days. Things change, right?

owenb 14y ago

Hi carlsednaoui As the creator of SocketStream, I am very keen to know how this error occurred. I believe it relates to the ulimit issue Paul mentioned in another comment which was fixed some time ago (i.e. the file was there, but the user was out of file descriptors)... not sure yet. Either way, we need to catch the exception properly. As a general tip to all those hosting a Node app in production, you can catch uncaught exceptions with: process.on('uncaughtException', function(err) { console.log(err); }); This ensures anything which goes wrong unexpectedly will be logged to your console, rather than sent to the browser - not good! SocketStream doesn't currently do this for you by default, but maybe it should (in production mode). It's something I will consider implementing in the near future. So far my focus has been on creating a great dev environment. It's very encouraging to see Dashku stand up to thousands of simultaneous users (once the ulimit issue was fixed), but I'm the first to admit more work is needed to ensure SocketStream is rock solid in production. It will take time but, thanks in part to experiences like today's, we'll get there. Great job Paul. Owen

zenocon 14y ago
I'm building a fairly large app right now with SocketStream and I just want to say that it is a joy to use. It really is a great dev. environment...flexible, useful, lightweight, and intuitive even without a ton of documentation.