When I deployed my play application I built the package using:
dist
This created a file that I can run on my server like:
sudo ./bin/app-name -Dhttp.port=9090
This works fine for testing but how can I run this process in the background?
I will eventually have to use upstart or some sort of process monitoring tool to make sure this process is running after server reboots etc.
Using play 2.3.x
Since you are on ubuntu
sudo ./bin/app-name -Dhttp.port=9090 &
should do the trick.
Ceating the upstart script is also fairly easy https://askubuntu.com/questions/18802/how-to-correctly-add-a-custom-daemon-to-init-d
In your case it would be in /etc/init/app-name.conf and look like
# app-name
#
start on stopped rc RUNLEVEL=[2345]
stop on runlevel [!2345]
respawn
exec $PATH_TO_APP/bin/app-name -Dhttp.port=9090
Of course you will want to change the RUNLEVEL and the PATH_TO_APP
That of course depends on the system at which you're deploying the app, anyway in general you need to run it as a deamon.
Refer to your system's documentations, I'm pretty sure that you will find tutorial very soon.
Related
Hi I'm trying to sort of autostart an applocation in Wayland, so that it starts after the sesktop is visible. I can start it manually via ssh via openvt but the problem is it wont start if I add it for instance into a service.
It just crashes. Does any one know how to autostart an app like that?
I'm using Poky (yocto) 2.1.2 with renesas' meta-renesas bsp 2.19 wayland 1.11
Update:
To be more precise it is Yocto's Poky built for Renesas' R-Car with wayland as manager. Poky 2.1.2
As Fl0v0 mentions, it depends on which init system you use.
If you use sysvinit, you have to mention this in your script:
# Required-Start: <wayland service>
On systemd:
a.service
[Unit]
After=b.service
Original sources: sysvinit and systemd
So I have finally figured it out what I was doing wrong.
Tu put it short I had to use openvt to start the application (and curiously some delay in seconds despite using After=weston.service ) and the applications started successfully.
I'm trying to run a swift based web server using Kitura on Ubuntu.
This is following command to start hello word server.
.build/debug/helloworld
I can launch standalone process using .build/debug/helloworld &
but launching with that creates multiple process if execute again.
Or I've to kill old process then start new If I want to run only single process.
I've followed following tutorial to get server up running. But don't want to use Bluemix to deploy application. Instead I want to launch it on AWS ubuntu.
http://www.kitura.io/en/starter/gettingstarted.html
I assume there must be more easy and proper way to do this.
As you can see I'm almost newbie for servers.
You have to kill the Kitura process in order to stop a Kitura Server app - there is no other way to stop it.
If you just want to test your server you can run it inside a screen session. Screen is an essential utility for managing remote servers via ssh.
If you want to run it properly as a service/daemon you should look into systemd.
I've followed instructions online to set up a Telescope instance on my DigitalOcean droplet, but it won't start with Upstart.
I'm able to run the server successfully manually, but the Upstart task doesn't fire when the server boots. I'm sure I should be looking at a log file somewhere to discover the problem, but I'm not sure where.
I've looked for the location of upstart logs, but I'm not having any luck. Either you have to add something to your script to make it log, or it just does it according to accounts online, but neither of those seem to be the case for me.
When I try to search for help on Upstart, I'm also seeing people saying I should be using systemd instead, but I can't figure out how to install it on CentOS 6.5.
Can anyone help me figure a way out of this labyrinth?
I use Ubuntu server 14.04, and my upstart logs are located in /var/log/upstart
The log usually contains stdout from the job, and it should help you understand what's wrong.
My guess is that when the server boots and tries to run your job, MongoDB is not yet ready so it fails silently.
Try installing the specific MongoDB version that Meteor is using at the moment (2.4.9) using these docs :
http://docs.mongodb.org/v2.4/tutorial/install-mongodb-on-ubuntu/
The most important thing is to get upstart support for MongoDB, this will allow us to catch mongod launch as an event.
You can then use this syntax in your upstart script :
start on started mongodb
This will make your node app start when mongo is ready.
I've created a gist with the scripts I wrote to setup a server ready for Meteor app deployment, it's a bit messy and probably specific to Ubuntu but it might help you.
https://gist.github.com/saimeunt/4ace7975b12df06ee0b7
I'm also using demeteorizer and forever which are two great tools you should probably check.
I have program that I need to run at startup in the background, so far I have it in rc.local like so:
sudo ./simple_program &
However this does not take into consideration if the program crashes. I need it so that whenever the program crashes, it is restarted again.
I think the approach is to write a bash script and run that instead in rc.local, where the bash script calls the simple_program and reruns it if needed. However, I'm not quite sure exactly what to do here. Could someone provide me a template?
Try with monit or daemontools, they are specifically designed to supervise other processes
I want to deploy a PSGI scripts that runs in Apache2 with Plack. Apache is configured with:
<Location "/mypath">
SetHandler perl-script
PerlResponseHandler Plack::Handler::Apache2
PerlSetVar psgi_app /path/to/my/script.psgi
</Location>
When I test the script with plackup, the --reload parameter watches updates on the .psgi file. In the production environment it is fine that Apache and Plack do not check and restart on each change for performance reasons, but how can I tell them explicitly to restart Plack::Handler::Apache2 and/or the PSGI script to deploy a new version?
It looks like Plack regularly checks for some changes but I have no clue when. Moreover it seems to create multiple instances, so I sometimes get different versions of script.psgi when at /mypath. It would be helpful to manually flush perl response handler without having to restart Apache or to wait for an unknown amount of time.
The short answer is you can't. That's why we recommend you to use plackup (with -r) for quick development and use Apache only for deployment (production use).
The other option is have a development apache process, and set MaxRequestsPerChild to a really small value, so that you will get a fresh child spawned in a very short period of time. I haven't tested this, and doing so will definitely impact the performance of your entire httpd, if you run the non-development application running on the same process (which is a bad idea in the first place anyway).
Apache2::Reload (untested)
You can move your application out of the appache process,
e.g.
FastCgiExternalServer /virtual/filename/fcgi -socket /path/to/my/socket
an run your programm with
plackup -s FCGI --listen /path/to/my/socket --nproc 10 /path/to/my/script.psgi
This way you can restart your application without restarting apache.
if you save the pid of the main fcgi process (--pid $pid_file)
you can easyly restart an load your new code.
There is also a module avail to manage (start,stop, restart) all your fcgi pools:
https://metacpan.org/pod/FCGI::Engine::Manager::Server::Plackup (not tested)