Meteor server side remote debugging - node.js

Versions
I'm using Meteor 1.0.3 and node 0.10.35 on a small Ubuntu Server 14.04 LTS (HVM), SSD Volume Type - ami-3d50120d EC2 instance.
Context
I know how to do server side debugging on my development box, just $ meteor debug and open another browser pointing to the url it produces -- works great.
But now, I'm getting a server error on my EC2 instance I'm not getting in development. So I'd like to set up a remote debug session sever side.
Also, I deployed to the EC2 instance using the Meteor-up package (mup).
EDIT
In an effort to provide more background (and context) around my issue I'm adding the following:
What I'm trying to do is, on my EC2 instance, create a new pdf in a location such as:
application-name/server/.files/user/user-name/pdf-file.pdf
On my OSX development box, the process works fine.
When I deploy to EC2, and try out this process, it doesn't work. The directory:
/user-name/
for the user is never created for some reason.
I'd like to debug in order to figure out why I can't create the directory.
The code to create the directory that works on my development box is like so:
server.js
Meteor.methods({
checkUserFileDir: function () {
var fs = Npm.require('fs');
var dir = process.env.PWD + '/server/.files/users/' + this.userId + '/';
try {
fs.mkdirSync(dir);
} catch (e) {
if (e.code != 'EEXIST') throw e;
}
}
});
I ssh'd into the EC2 instance to make sure the path
/server/.files/user/
exists, because this portion of the path is neccessary in order for the above code to work correctly. I checked the path after the code should have ran, and the
/user-name/
portion of the path is not being created.
Question
How can I debug remote server side code in a easy way on my EC2 instance, like I do on my local development box?

Kadira.io supports remote errors/exceptions tracking. It allows you to see the stacktrace on server side exceptions in the context of your meteor methods.
See https://kadira.io/error-tracking.html for more detail.

It seems in my case, since I'm using Meteor-up (mup), I can not debug per-say, but get access to the remote EC2 instance server console and errors by using command $ mup logs -f on my development box.
This effectively solves my issue with being blind on the server side remote instance.
It still falls short of actual debugging remotely, which speeds up the process of finding errors and performance bottlenecks, but it's all we have for now.

For someone who still searching:
#zodern added server-side debugging of meteor apps to great meteor-up tool:
https://github.com/zodern/meteor-up/pull/976
Do mup meteor debug in deployment dir and you will be almost set, just follow the text.

Related

PG (Node-Postgres) Pool Hangs on Connect ... But Only Inside Gatsby?

NOTE: This is mainly a question about the pg or Node-PostgreSQL module. It has details from Gatsby and Postgraphile, but I don't need expertise in all three, just pg.
I have a database that works great with a PostGraphile-using Express server. I can also acces it via node at the command line ...
const { Pool } = require("pg");
const pool = new Pool({ connectionString: myDbUrl });
pool.connect().then(() => console.log('connected'));
// logs 'connected' immediately
The exact same database also previously worked great with Gatsby/PostGraphile via the gatsby-source-pg plug-in ... but recently I changed dev machines, and when I try to build or run a dev server, Gatsby hangs on the "source and transform nodes" step. When I debug it, it's hanging on a call to pool.connect().
So I literally have two codebases both using PostGraphile, both with the same config, and one works and the other doesn't. Even stranger, if I edit the source code of the Gatsby plug-in in node_modules, to make it use the exact same code (which I can run at the command line successfully) ... it still hangs.
The only thing I can think of is that some other Gatsby plug-in is using up all the connections and not releasing them, but as far as I can tell (eg. by grep-ing through node_modules) no other plug-in even uses pg.
So really I have two questions:
A) Can anyone help me understand why connect would hang? Bonus points if you can help me understand why it would do so with a known-good config and only inside Gatsby (after some environmental factor changed)?
B) Can anyone help me fix it? If it might be some sort of "previous code forgot to release connections" issue, is there any way I can test for that? If I could just log new Pool().areYouBroken() somehow that would be amazingly useful.
Try:
npm install pg#latest
This is what got my pool/connection to start working as expected.
Annoying answer: because of a bug (thank you #charmander). For further details see: https://github.com/brianc/node-postgres/issues/2300
P.S. I never did find any sort of new Pool().areYouBroken() function.

npm open is not working while deploying it in server?

I have a nodejs code where at some point it uses a new tab for showing results.I got npm-open where it show my result in a new tab of the browser.But when i deploy it in a linux server, its neither opening a new tab nor throwing any error?
open( req.protocol + '://' + req.get('host')+"/view-document/?logos="+ logos+"&comp_name="+result_3[0].name +"&emp_name="+empname+"&start_date="+sdates+"&end_date="+edates+"&position="+designation+"&template=template1"+"&emp_id="+emp_id+"&issue_date="+issue_date+"&title="+title, function (err) {
if ( err ) {
res.redirect("/view-document/?logos=" + logos+"&comp_name="+result_3[0].name +"&emp_name="+empname+"&start_date="+sdates+"&end_date="+edates+"&position="+designation+"&template=template1"+"&emp_id="+emp_id+"&issue_date="+issue_date+"&title="+title);
return;
}
});
How could it?
The open command is a way to make your script interact with the OS it is running on, telling it to open a URL, image, etc. If you run your script on your local machine, this is fine and works as expected.
If you run your script on a server, there is no way it can communicate its request to your local machine. Think about it – should a random webpage/server have the ability to interact with the OS on client machines?
To make something like this work, you will need to split your script into two parts:
the parts that should reside on the server
the utility script which will communicate with the server and, when needed, run the open command

Err_connection_refused using meteor uploads

I am deploying a meteor application to a digital ocean droplet with meteor upload. Everything goes well, the application gets deployed, database works, seeding of data works etc. But there is one problem i can't seem to be able to solve.
I use the meteor-uploads package (https://github.com/tomitrescak/meteor-uploads) for file uploads. Locally everything goes well, the file gets uploaded, finished callback gets called etc. But once I have deployed the application to the server it keeps giving me on of these errors, :
POST http://*ip*/upload net::ERR_CONNECTION_REFUSED
POST http://*ip*/upload net::ERR_EMPTY_RESPONSE
POST http://*ip*/upload net::ERR_CONNECTION_RESET
Any ideas are welcome, I have searched all over for a solution but none seems to fit my problem. I also installed to a fresh droplet but that didn't help. In none of my browsers (Mac Chrome, safari & firefox) does it work, on my phone (Android 5.0) I get the same errors. I am using the newest Meteor version 1.1.0.1
On local host you don't need to set the environmental variables, but the host services provides you should.
Check this tutorial to see how to put the environment variables.
Because the file-upload needs a startup-server-configuration, like this.
//file:/server/init.js
Meteor.startup(function () {
UploadServer.init({
tmpDir: process.env.PWD + '/.uploads/tmp',
uploadDir: process.env.PWD + '/.uploads/',
checkCreateDirectories: true //create the directories for you
})
});
But im not sure if putting this on a startup will work on digital ocean, like i say you you enter it, run printing and check if the /.uploads/ exists

How to disable the debug remote port in node-webkit desktop app

I wan't to protect the code of my node-webkit desktop application packaged in an exe file.
The problem is not on the file directly but with the dedicated port for remote debugging.
Perhaps I haven't understood something but, on Windows, if I execute a "netstat -a -o" command, I see an open port associated to the application and if I open this port on my browser, I have a page with "Inspectable WebContents" and a link to the webkit application.
With this debug window, it's possible to access to all the sources of the app and I don't know how to disable this feature.
For now, I think there is no actual way to disable remote debugging in nw.js.
Even so, according to the wiki, remote debugging seems to only be executed through the command line switches. Therefore you can block the chromium command line switches (or only --remote-debugging-port) to prevent arbitrary remote debugging by user until nw.js supports disabling functionality of remote debugging.
For instance:
const gui = require('nw.gui');
const app = gui.App;
for (let element of app.fullArgv) {
// app.argv has only user's switches except for the chromium args
if (app.argv.indexOf(element) < 0) {
app.quit(1); // invalid args!
}
}
However, I am not quite sure the above code could protect your application code, because the nw.js is using Chromium internally. So that, the application code would be extracted in temporary folder on initialization. Whereas above solution isn't really protect your nw.js application. See more details: https://github.com/nwjs/nw.js/issues/269
Note: node-webkit has changed name to nw.js

How to detect if an app is running with Cloud9?

I'm developping a node application, sometimes with Eclipse (locally) and sometimes with Cloud9 (remotely). As I'm using a database, I have one local with mongoDB and another remote on mongoHQ.
If I dont want to use the DB on mongoHQ when I work locally, how could I tell my nodejs application (understand automatically detect) that my IDE is Cloud9 or another one ? I could use a simple local variable that I change each time I change IDE, but is it possible to do it automatically ?
One way to detect cloud9-ide is to check if C9_PROJECT environment variable is set:
if (process.env.C9_PROJECT) {
console.log('Running on C9 IDE');
} else {
// ...
}
There are also other variables prefixed with C9. You can check them if you want to.

Resources