I recently downloaded and managed to start an OrientDB server/database on an AWS EC2 Linux 14.04 (I think the name is) server for an application I want to set up. I started OrientDB "as usual" by running ./server.sh in the terminal via SSH link to the EC2 server. All works fine and I can query the database while at the computer. But as soon as I leave my computer and the SSH link is broken (for example when closing the computer), so is the database, i.e. it stops.
Is there a way to go around this or do I have to set up the database in some other way?
OrientDB is provided as AWS AMI. Take a look to
http://orientdb.com/orientdb-amazon-web-services/
If you want to DIY, follow the instructions provided on
http://orientdb.com/docs/last/Unix-Service.html
Update: new link to doc:
https://orientdb.com/docs/last/admin/Unix-Service.html
Hope this helps
you can try putting full path to server.sh into /etc/rc.local before exit 0 and reboot the instance
Before running the server, run the command:
screen
This will create a persistent environment which will allow your process to keep running after you disconnect.
When you reconnect, you can use this command to reconnect to that environment:
screen -r
Related
How to run nginx and Node.js at server startup?
In order to start Amazon EC2 with AWS Auto Scaling, I must directly connect to EC2 to run nginx and Node.js.
Can this be done for Auto Scaling?
In Amazon EC2, I want to run nginx with Node.js during EC2 startup by Auto Scaling.
EC2 is set up as an Auto Scaling group using images. I want to run EC2 Node.js applications and nginx, which are started by Auto Scaling, together with the EC2 server startup.
For nginx, I can run the executable with chkconfig, but the Node.js application will run as pm2, using the code written in package.json.
How can I run nginx and Node.js with EC2 startup and let the new EC2 -- started with Auto Scaling -- respond properly?
comment reply :
I don't want to run node.js using "node app.js" command.
I want to run node.js by package.json ( script )
ex.
"start": "NODE_ENV=production PORT=3000 pm2 start server.js -i -1"
How can I do this?
Your suggestions are using linux server init script file.
But, I want to set NODE_ENV, PORT and use pm2 command.
solution
I solved the problem.
When Linux booted, I tried to use the script file to automatically run node.js.
I created the script file and made the shell script run automatically after linux booted, but it did not seem to be a good idea.
Alternatively, pm2 startup and ecosystem.config.js can be used to solve problems flexibly.
Thank you for your reply.
This has nothing to do with autoscaling. It most often has to do with the EC2 AMI (Amazon Machine Image) that the autoscaler is launching your EC2 instances with, and possibly also with the "user metadata" that you are passing to the instance when it launches. These are the only two things that impact what an EC2 instance does when and after it starts up, up until it starts communicating with the outside world.
So what you need to do is create an AMI that is set up so that the right things launch when an EC2 instance is launched from that AMI. What you'd do is take the AMI you want to use as a starting point, launch that AMI into an instance, make the necessary changes and installations you want, and then save off a new AMI. Then change your autoscaling group to launch new instances with that new AMI.
You could alternately send a script in your "user metadata" that launches things, but this is rarely what you want to do". Most of the time, you want to have your AMI do the right thing.
It's also possible that you are using some sort of post-boot provisioner, like Chef, Ansible or Chef Habitat. If you are, that's where you'd set all of this stuff up. You'd want that system to do the work you're describing. But if you're doing that, what I have said earlier still applies. For this to work, you'd often have also built a custom AMI that has parts of the provisioning system already built into it, so that that system can connect into it and provision it. It's possible for these systems to start from a generic AMI as well. It depends on the system.
I'm newbie using GCP and his Compute Engine Service. I've deploy a Linux Ubuntu Image an it's running like a charm, but I have a issue running Node JS backend.
Let me explain it better:
I'm connecting using Web Browser SSH terminal or GCloud Shell ssh, and it way works running node app.js my backend starts working. But after a time, the sessions stop and my backend service stop working as well. At this time every time when I need to work have to re-activate the service each time.
How could I do for this service works in background and not depends that my ssh terminal are opened?
Thanks a lot in advance.
What actually happen is you are starting your nodejs application using an client which is parent process. So if after sometime the connection is lost of some xyz seconds the parent process dies killing your node application. Now what you can do is use screen. On ubuntu you would do something like this.
sudo apt-get install screen
after successful install run the screen command. Now you will be thrown a brand new terminal. Here you can run your nodejs code which will never die. Since screen runs your application in background. More information here
A good solution could be to use a startup script. To insert a startup script into your already created instance you need to go to this link [1]. When you have your startup script inserted in the metadata field you just need to restart your Instance and then should work perfectly without depending of the ssh session.
[1] https://cloud.google.com/compute/docs/startupscript#startupscriptrunninginstances
I've created this npm package, to make your node app run as a service on your linux machine. Please try it out.
It creates a systemctl service on your machine and runs it as a background service.
I am not sure if this is the correct place to ask my question, but really I am out of ideas, and my clock is ticking.
In short, I got a new machine that I need to make development ready.
This project is based on rather old program versions, that is a task to update.
In short I have set up the Vagrant (1.8.1) in VirtualBox (5.0.14). Chef (0.10.0) created all dependencies successfully and I can SSH to machine and see all is fine, all services are running as set in VagrantFile.
Vagrant box is latest ubunty/trystu64. My host machine is MacOs HighSierra(10.13.3).
Now, I open for example an mySQL editor (mySQL Workbench) and it connects to the Box, I can see DB and manipulate it.
My problem is with the NodeJS (I think). When I run my tests, it simply refuses to connect to the Box. More precisely, it attempts to connect to 127.0.0.1: 3306 (mySQL) and it errors. While MySQL Workbench performs the same connection without problems.
It seems the port forwarding in Vegrant works fine, as mySQL workbench is being forwarded to a box. Nodejs is not being forwarded, or something.
Is it Node doing it? Something else that I need to allow?
I have tried many different things, I have lost count. And always the same issue.
Is there something that I can do to Node, so it behaves as mySQL Workbench? Any idea is appreciated.
This identical setup used to work before, but not now.
I'm using Amazon EC2 to host my Node.js server. I connect through ssh from my desktop, and once I run my server via ssh, I can turn my console off and everything will still work, obviously, since the process is running on my remote EC2 hosting server. But once I ssh again, I know the Node process is still running, but there seems to be no way to view the process logs, and this server is still in early beta versions that the console logs are important. Any help?
You could redirect stdout/stderr to a file, which would allow you to use ordinary tools like cat and tail to view the logs.
If you don't want to write the log output to file(s), you could start the process in screen or tmux or similar and attach to the session later from ssh.
I have deployed a Bitnami AMI of NodeJS on an AWS micro instance. After starting my node app, everything works fine.
After some time without any activity, the app which is attached to port :3000, seems to shut down. When this happens on refreshing the page my browser gives the message:
Network Error (tcp_error)
A communication error occurred: "Connection refused"
The Web Server may be down, too busy, or experiencing other problems preventing it from responding to requests. You may wish to try again at a later time.
The AWS console shows the instance is still running and the Bitnami build still responds with the standard message on port 80.
Forever (https://github.com/nodejitsu/forever) is also a useful tool for this kind of thing, and it gives you a little more control than nohup or screen.
As we discussed in comments, the problem was binding the node process to SSH session.
You can use nohup or screen to launch the node process in an instance not bound to session.
I suggest using screen because the function of returning to launched instance is essential for maintenance/updating.
Related: How to run process as background and never die
Related: Command-Line Interface tool to run node as a service
Besides configuring an EC2-instance you can also use the PaaS-solution of AWS, namely Elastic Beanstalk. They have also support for Node.js and it's super easy to deploy your apps using this service.