I have looked for answer for this question and have to find anything quiet like what I experience!
I set up an Ubuntu instance on AWS, standard configurations, medium tier.
I ssh into the server, and then I have a script running in Node, which I launch with sudo nodejs server.js .
When it runs, it has a few REST endpoints which work just fine, and those write to a mongodb (which, also works just fine). However, if I leave my computer and come back the next day, I get the standard SSH broken pipe, which is fine. But! When I try to use my REST api at that point, the node server.js is clearly not running.
I am the only person consuming this api, so I don't think errors are bringing it down.
Has anyone experience anything like this? Perhaps there is a configuration I am missing?
A friend just answered it for me,
sudo nodejs server.js & > mylog.out
This makes it run in the background and print the stdout to a log instead of nowhere (nowhere due to broken pipe)
Related
There are a lot of pieces so I don't expect anyone to be able to answer this without seeing every configuration. But maybe people can tell me how to look for diagnostics or kind of how the major pieces fit together so that I can understand what I'm doing wrong.
I have a Tencent CVM instance running Ubuntu Server.
I also have a domain name pointing to the ip address of that server.
I start an nginx service to listen to port 1337 and pass requests to example.com/parse
I have mongodb running inside of a docker container, listening on port 27017.
Inside of index.js, I have the databaseURI set as 'mongodb://localhost:27017/dev' and the SERVER_URL set as 'https://example.com/parse'
When it's time to deploy the Parse Server instance, I use screen inside of my current ssh session, run npm start, and then detach the screen, and then kill my ssh session by closing the terminal.
Finally, I run the parse dashboard on my local machine with serverURL 'https://example.com/parse'
And everything works great. I add items to the database via the test page that comes with the Parse Server repo. I add items to the database via cloudcode calls from Python. I add and delete classes and objects via the dashboard. The behavior is exactly like I should expect.
And it continues that way for anywhere between 12-72 hours.
But after a few days of normal operation, it will happen that I open parse dashboard and everything is gone. I can start adding things again and everything works right, but nothing persists for more than 72 hours.
There's a lot I don't understand about the anatomy of this, so I figured maybe using screen and then detaching and closing the terminal causes some process to get killed and that's my mistake. But when I run top, I can see everything. I can see npm start is running. I can see mongo is running. When I docker ps to check the container, it's still there doing fine. The nginx service is still running.
Can anyone suggest a way for me to start diagnosing what the problem is? I feel like it's not any of the configs because if that was the problem, it wouldn't work fine for so long. I feel like it must be how I'm deploying it is causing something to reset or causing some process that's supposed to be always running to die.
Edit: For posterity I'll summarize the below as a solution in case you've come here struggling with the same issue. #Joe pointed me to db.setProfilingLevel(), level 2 with the slowms=0 option for max verbosity. Those logs are written to the file indicated within mongodb.conf. Docker doesn't persist storage by default, so you should have a named volume. The syntax is $docker volume create <volume_name>. And the syntax to attach the volume when you create the container is to add a v flag like -v <volume_name>:. And finally, I was running mongodb in a container because that's the workflow I saw in tutorials. But it's solving a problem I didn't have and it was simpler to start mongodb as a service without a container.
I don't have Sudo access, so currently i can't install 'Forever' https://www.npmjs.com/package/forever
Instead i am simply using 'Screen'.
I am running a node.js server, at a random point, the node server stops, and screen exits. I cannot seem to collect any error data on this. I seem to be completely unaware of why its happening and cannot think of a way to catch what is happening. It doesn't happen often (maybe 1 time per day). When i load putty back up and login to my Apache server through terminal, i type screen -x or screen -r and it tells me there are no screens attached. The node server process definitely stops because the app it runs stops working.
Obviously i can't post all the code here, there is tons of it. But everything appears to work wonderfully, except every now and then, something goes wrong and it closes the attached screen.
If there was a problem with the node server, i would expect a crash, and the attached screen would stay attached. There would be an error outputted to the terminal for me to see when i open it. But in this case, it totally closes the attached screen.
Does anybody know what kind of error can cause this?
On a side note, is there an alternative to 'Forever' that can be installed without Sudo access?
My node version wasn't correct which is why Forever wasn't installing. I didn't need SUDO after all. I am now using Forever and hopefully this will shed light on what is going on as i have a out.log file which should catch whatever the problem is. :-)
I know to start my Node app I type in the Win shell, node app.js.
But this is obviously not how a webhost would maintain a Node webserver (ie what happens if there is a power outage, a Node exception, etc).
I see things like Forever and running Node as a Windows service, but I feel like the creator of Node must have had a different idea? Something like Apache is installed as a Windows Service so that it runs even if the server reboots - what is the correct method of doing this for Node? I don't like the idea of introducing another piece of software just to keep the server going.
Thanks.
The problem is that many systems do not do that. For instance MongoDB doesn't even run like that on windows.
The best solution I have found is this https://nssm.cc/
Also you have to consider even on Linux you need to run something like upstart to keep node programs running when you close the console.
Koa has implemented not having a web server shut down when one page has an error. My question.... is this error handling behaviour robust enough that one no longer needs to use Forever when hosting a node site?
You should still use forever (or nodemon, a bit easier to use in some cases) to keep your server running. There are other things that can cause it to crash in a production environment, not just bad requests.
In development, I've seen insane uptime on some koa apps without using forever/nodemon, but I would not do this in production. It's asking for a 3 am phone call :)
If you're using Linux/Unix, you should also consider using tmux to keep it running in a separate terminal session, or it can timeout with your terminal session. (Type tmux new -s koa to get started). Here's an article on using tmux with upstart: https://bowerstudios.com/node/953
We have a whiteboard application powered by NodeJS sitting on a 'cloud' server (rackspace cloud). I recently scaled our server up to accommodate for the anticipated traffic with our launch, and in the process it shut down NodeJS. We are launching our product in a few hours, and our NodeJS developer has gone for the day.
The whiteboard application is supposed to run at http://rayku.com:8001 (the port is opened). However, it's not working because the port isn't listening to anything with NodeJS shut down.
I honestly have no idea which js file to run in order to start NodeJS for the whiteboard. There are many js files in a 'whiteboard' folder. Do you know what type of code I should look for that might suggest it is the right one? Or, do you know what types of logs I can dig up that might point me in the right direction?
Much appreciated
Look for app.js, server.js or something similar. It isn't required but a lot of people use app.js from what I have seen.
node or nodejs is typically the command to start. You may need to set environmental variables or arguments depending on how the developer set things up.
Also make sure to run it with screen or forever so it doesn't quit when you log out.
For common code. createServer is probably what is used to open the server itself. That is consistent between the core libraries and a lot of the frameworks. There might be another file that loads the module prior to executing so running might not work.