I have followed some posts and tutorials as well to create a script to start meteor project when server restart. i have followed answer mentioned in : How to run meteor on startup on Ubuntu server
Then I gave executable permission to script with "chmod +x meteor-server.sh".
I have tried to put this script in /etc/init.d and /etc/init folders but meteor project does not start at the reboot. I'm using ubuntu 16.04.
I would be grateful if you can show me the fault that i have done. Following code is my "meteor.server.sh" script file.
# meteorjs - meteorjs job file
description "MeteorJS"
author "Jc"
# When to start the service
start on runlevel [2345]
# When to stop the service
stop on runlevel [016]
# Automatically restart process if crashed
respawn
# Essentially lets upstart know the process will detach itself to the background
expect fork
# Run before process
pre-start script
cd /home/me/projects/cricket
echo ""
end script
# Start the process
exec meteor run -p 4000 --help -- production
First of all, there's already a very good tool mupx that allows you to deploy meteor projects to your own architecture, so there's really no need to do it by yourself unless you have a very good.
If you really need to deploy manually, this will take several steps. I am not going to cover all the details because you're specifically asking about the startup script and the remaining instruction should be easily accessible in the Internet.
1. Prepare your server
Install MongoDB unless you are planning to use a remote database.
Install NodeJS.
Install reverse proxy server, e.g. Nginx, or haproxy.
Install Meteor, which we will use as the build tool only.
2. Build your app
I am assuming here that you already have the source code of your app put on the server to which you're planning to deploy. Go to your project root and run the following command:
meteor build /path/to/your/build --directory
Please note that if /path/to/your/build exists it will be recursively deleted first, so be careful with that.
3. Install app dependencies
Go to /path/to/your/build/bundle/programs/server and run:
npm install
4. Prepare a run.sh script
The file can be of the following form:
export MONGO_URL="mongodb://127.0.0.1:27017/appName"
export ROOT_URL="http://myapp.example.com"
export PORT=3000
export METEOR_SETTINGS="{}"
/usr/bin/env node /path/to/your/build/bundle/main.js
I will assume you put it in /path/to/your/run.sh. A couple of notes here:
This form of MONGO_URL assumes you have MongoDB installed locally.
You will need to instruct your reverse proxy server to point your app trafic to port 3000.
METEOR_SETTINGS should be the output of JSON.stringify(settings) of whatever settings object you may have.
5. Prepare upstart script
With all the preparations we've made so far, the script can be as simple as
description "node.js server"
start on (net-device-up and local-filesystems and runlevel [2345])
stop on runlevel [016]
respawn
script
exec /path/to/your/run.sh
end script
This file should go to /etc/init/appName.conf.
Finally i got it to work. I have used following 2 scripts to run meteor on the startup.
First i put this service file(meteor.service) in /etc/systemd/system
[Unit]
Description = My Meteor Application
[Service]
ExecStart=/etc/init.d/meteor.sh
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=meteor
[Install]
WantedBy=multi-user.target
I have called a scipt using this service. I put this following script(meteor.sh) in /etc/init.d
#!/bin/sh -
description "Meteor Projects"
author "Janitha"
#start service on following run levels
start on runlevel [2345]
#stop service on following run levels
stop on runlevel [016]
#restart service if crashed
respawn
#set user/group to run as
setuid janitha
setgid janitha
chdir /home/janitha/projects/cricket_app
#export HOME (for meteor), change dir to plex requests dir, and run meteor
script
export HOME=/home/janitha
exec meteor
end script
I make both these file executable by using
chmod +x meteor.service
chmod +x meteor.sh
And i have used following two commands to enable the service
systemctl daemon-reload
systemctl enable meteor.service
I used this configurations successfully
In /etc/init.d add a file called meteor.sh
#!/bin/sh
export HOME="/home/user"
cd /home/user/meteor/sparql-fedquest
meteor --allow-superuser
You must give executions permissions to meteor.sh
sudo chmod 644 meteor.sh
Also you must create meteor.service in /etc/systemd/system
[Unit]
Description =Portal of bibliographic resources of University of Cuenca
Author = Freddy Sumba
[Service]
ExecStart=/etc/init.d/meteor.sh
Restart=always
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=meteor
[Install]
WantedBy=multi-user.target
Also you must give permissions to meteor.service
$ sudo chmod 644 meteor.service
Then, we need add the service to this start each time that the server reboot
$ systemctl enable meteor.service
And finally start the service
$ service meteor start
Related
Im trying to run my Hello World application using a service in the systend file. the steps i followed
mkdir ~/HelloWorld
cd ~/HelloWorld
dotnet new console
sudo mkdir /srv/HelloWorld # Create directory /srv/HelloWorld
sudo chown yourusername /srv/HelloWorld # Assign ownership to yourself of the directory
dotnet publish -c Release -o /srv/HelloWorld
/srv/HelloWorld/HelloWorld # it outputs'Hello World!'
I then create the HelloWorld.service file:
[Unit]
Description=Hello World console application
[Service]
ExecStart=/srv/HelloWorld/HelloWorld
SyslogIdentifier=HelloWorld
User=admin
[Install]
WantedBy=multi-user.target
I then copy the file to systemd
sudo cp HelloWorld.service /etc/systemd/system/HelloWorld.service
sudo systemctl daemon-reload
sudo systemctl start HelloWorld
sudo systemctl status HelloWorld
##When runing status it gives me
Acrive failed (Result:exit-code)
Process ExecStart=/srv/HelloWorld/HelloWorld (code=exited, status=203/EXEC)
(When i run my Heloworld using "/srv/HelloWorld/HelloWorld " in the console it does log Hello WOrld )
I'm assuming you were following my blog post on running console apps on Linux (RHEL), based on the commands and comments that are matching. Thank you for reading and sorry you ran into issues. I happen to be refreshing this blog post and ran into the same issue as you, which is why I started Googling and found your question.
Unfortunately, RHEL and dotnet made some changes and the original instructions don't work anymore. Luckily, I was able to resolve it by making some modifications to the service file:
[Unit]
Description=Hello World console application
[Service]
# systemd will run this executable to start the service
ExecStart=/usr/bin/dotnet /srv/HelloWorld/HelloWorld.dll
# to query logs using journalctl, set a logical name here
SyslogIdentifier=HelloWorld
# Use your username to keep things simple.
# If you pick a different user, make sure dotnet and all permissions are set correctly to run the app
# To update permissions, use 'chown yourusername -R /srv/HelloWorld' to take ownership of the folder and files,
# Use 'chmod +x /srv/HelloWorld/HelloWorld' to allow execution of the executable file
User=admin
# This environment variable is necessary when dotnet isn't loaded for the specified user.
# To figure out this value, run 'env | grep DOTNET_ROOT' when dotnet has been loaded into your shell.
Environment=DOTNET_ROOT=/usr/lib64/dotnet
[Install]
WantedBy=multi-user.target
Specifically, pay attention to how I'm invoking the dotnet executable and passing the path to the HelloWorld.dll as an argument. This is also what the HelloWorld executable file is supposed to do, but for some reason, no longer works.
I'm not sure if you're using RHEL or how you installed .NET, so you may want to replace the path to the dotnet executable (/usr/bin/dotnet), to the path where your dotnet executable is loaded.
The easiest way to find this path is by running which dotnet.
Alternatively, you can find the path by running dotnet --info to figure out where the SDK is installed, and start digging for the dotnet executable.
Also, the DOTNET_ROOT env variable had to be set in the service for me. I used the env | grep DOTNET_ROOT command to find the correct value for the env variable.
Next time, feel free to message me, so I can be notified and update my content more quickly. Let me know if this works!
I built a Nodejs project and now it runs smoothly.
I use forever service for running file in background but if server get restarted
the daemon won't be started automatically and should be started manually.
I want to run the daemon even the server get rebooted
You could add the forever command in .bash_profile so that every time the server restart, your command will simply be also executed.
nano ~/.bash_profile
forever start app.js # add this command to the file, or whatever command you are using.
source ~/.bash_profile # very important, else changes will not take effect
Next time, on your server restart, your command will also run, hence creating a daemon of your node script.
Note: This is maybe not the best solution, but the one I have got.
Update
As #dlmeetei, suggested, you can also start your nodejs app like a service so that we can use the features given by a linux service.
First create a file in /etc/systemd/system, like:
touch /etc/systemd/system/[your-app-name].service
nano /etc/systemd/system/[your-app-name].service
Then, add and edit the following script according to your relevance.
[Unit]
Description=Node.js Example Server
#Requires=After=mysql.service # Requires the mysql service to run first
[Service]
ExecStart=/usr/local/bin/node /opt/nodeserver/server.js
# Required on some systems
# WorkingDirectory=/opt/nodeserver
Restart=always
# Restart service after 10 seconds if node service crashes
RestartSec=10
# Output to syslog
StandardOutput=syslog
StandardError=syslog
SyslogIdentifier=nodejs-example
#User=<alternate user>
#Group=<alternate group>
Environment=NODE_ENV=production PORT=1337
[Install]
WantedBy=multi-user.target
Enable the service, it will marks the service for starting up on boot.
systemctl enable [your-app-name].service
Manage the service
systemctl start [your-app-name].service
systemctl stop [your-app-name].service
systemctl status [your-app-name].service # ensure your app is running
systemctl restart [your-app-name].service
Reference: https://www.axllent.org/docs/view/nodejs-service-with-systemd/
Thanks #dlmeetei for sharing the link.
Couldn't seem to find a direct answer around here.
I'm not sure if I should run ./myBinary as a Cron process or if I should run "go run myapp.go"
What's an effective way to make sure that it is always running?
Sorry I'm used to Apache and Nginx.
Also what are best practices for deploying a Go app? I want everything (preferably) all served on the same server. Just like how my development environment is like.
I read something else that used S3, but, I really don't want to use S3.
Use the capabilities your init process provides. You're likely running system with either Systemd or Upstart. They've both got really easy descriptions of services and can ensure your app runs with the right privileges, is restarted when anything goes down, and that the output is are handled correctly.
For quick Upstart description look here, your service description is likely to be just:
start on runlevel [2345]
stop on runlevel [!2345]
setuid the_username_your_app_runs_as
exec /path/to/your/app --options
For quick Systemd description look here, your service is likely to be just:
[Unit]
Description=Your service
[Service]
User=the_username_your_app_runs_as
ExecStart=/path/to/your/app --options
[Install]
WantedBy=multi-user.target
You can put it in an inifiny loop, such as:
#! /bin/sh
while true; do
go run myapp.go
sleep 2 # Just in case
done
Hence, once the app dies due some reason, it will be run again.
You can put it in a script and run it in background using:
$ nohup ./my-script.sh >/dev/null 2>&1 &
You may want to go for virtual terminal utility like screen here. Example:
screen -S myapp # create screen with name myapp
cd ... # to your app directory
go run myapp.go # or go install and then ./myappfrom go bin dir
Ctrl-a+d # to go out of screen
If you want to return to the screen:
screen -r myapp
EDIT: this solution will persist the process when you go out of terminal, but won't restart it when it'll crash.
We have a series of node.js scripts on an Ubuntu (13.10) server that we want to keep up and running as much as possible, and restart automatically in the event of a server reboot. We've tried a few different techniques, but have yet to find a solution that works.
Setup: None of the scripts run on port 80, instead we run them on ports above 8000.
Node.js files are currently running in /usr/lib/sites/path/Node
We have set them up and running individually using Forever while running in the context of a well privileged (but not root) user, simply by running the following from the context of the folder containing the scripts:
forever start server_process.js
We want to run these scripts at server start up, and have some ability later (if needed) to restart them.
Upstart sounds like it should be the solution, but we've not yet managed to get it working. The following script starts, then stops without indicating why...
description "Our app"
version "1.0"
author "Nautilytics"
start on startup
stop on shutdown
expect fork
env FOREVER_PATH=/usr/bin/forever
env APPLICATION_DIRECTORY=/usr/lib/sites/path/Node
env APPLICATION_START=ourapp.js
env LOG_PATH=/var/log/ourapp.log
chdir /usr/lib/sites/path/Node
script
exec $FOREVER_PATH start --sourceDir $APPLICATION_DIRECTORY -f -v $APPLICATION_START >> $LOG_PATH 2&>1
end script
Through blunt trial and error, a couple of times we have been able to get errors that indicate that other files (required by ourapp.js) could not be found, as if the chdir has not worked or passed through into the forever start.
After scouring the internet for a solution, we decided to stick with nodejs and not use forever for this task. It was much easier and with respawn it does just about everything we needed forever to do for us.
start on runlevel [2345]
stop on shutdown
respawn
script
exec sudo nodejs /usr/lib/sites/path/Node/ourapp.js 2>&1 >> /var/log/ourapp.log
end script
A bit more secure upstart config script might be (hardened-nodejs.conf):
description "Managing and monitoring nodejs application"
# start when filesystem is mounted networking is up
start on (filesystem and net-device-up IFACE!=lo)
# stop on shutting down the system
stop on runlevel [016]
# application environment
# staging and development instances should use hardened-nodejs.override to define environment
env NODE_ENV=production
# respawn the job up to 10 times within a 5 second period.
# If the job exceeds these values, it will be stopped and marked as failed.
respawn
respawn limit 10 5
# ssl-cert group can read certificates
setuid www-data
setgid ssl-cert
exec /usr/bin/nodejs /usr/lib/sites/path/Node/ourapp.js 2>&1 >> /var/log/ourapp.log
One of solutions to run nodejs application listening on a low port might be to use capabilities tools.
If serving over SSL user or group must have read access to the certificate. Check ssl-cert package and this answer for basic concepts.
Have you checked process.cwd()? It could be that your process is running elsewhere.
I have recently completed the Wiki web development tutorial (http://golang.org/doc/articles/wiki/). I had tons of fun and I would like to experiment more with the net/http package.
However, I noticed that when I run the wiki from a console, the wiki takes over the console. If I close the console terminal or stop the process with CTRL+Z then the server stops.
How can I get the server to run in the background? I think the term for that is running in a daemon.
I'm running this on Ubuntu 12.04. Thanks for any help.
Simple / Usable things first
If you want a start script without much effort (i.e. dealing with the process, just having it managed by the system), you could create a systemd service. See Greg's answer for a detailled description on how to do that.
Afterwards you can start the service with
systemctl start myserver
Previously I would have recommended trying xinetd or something similar for finer granuarlity regarding resource and permission management but systemd already covers that.
Using the shell
You could start your process like this:
nohup ./myexecutable &
The & tells the shell to start the command in the background, keeping it in the job list.
On some shells, the job is killed if the parent shell exits using the HANGUP signal.
To prevent this, you can launch your command using the nohup command, which discards the HANGUP signal.
However, this does not work, if the called process reconnects the HANGUP signal.
To be really sure, you need to remove the process from the shell's joblist.
For two well known shells this can be achieved as follows:
bash:
./myexecutable &
disown <pid>
zsh:
./myexecutable &!
Killing your background job
Normally, the shell prints the PID of the process, which then can be killed using the kill command, to stop the server. If your shell does not print the PID, you can get it using
echo $!
directly after execution. This prints the PID of the forked process.
You could use Supervisord to manage your process.
Ubuntu? Use upstart.
Create a file in /etc/init for your job, named your-service-name.conf
start on net-device-up
exec /path/to/file --option
You can use start your-service-name, as well as: stop, restart, status
This will configure your service using systemd, not a comprehensive tutorial but rather a quick jump-start of how this can be set up.
Content of your app.service file
[Unit]
Description=deploy-webhook service
After=network.target
[Service]
ExecStart=/usr/bin/go webhook.go
WorkingDirectory=/etc/deploy-webhook
User=app-svc
Group=app-svc
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=deploy-webhook-service
PrivateTmp=true
Environment=APP_PARAM_1=ParamA
Environment=APP_PARAM_2=ParamB
[Install]
WantedBy=multi-user.target
Starting the Service
sudo systemctl start deploy-webhook.service
Service Status
sudo systemctl status deploy-webhook.service
Logs
journalctl -u deploy-webhook -e
After you press ctrl+z (putting the current task to sleep) you can run the command bg in the terminal (stands for background) to let the latest task continue running in the background.
When you need to, run fg to get back to the task.
To get the same result, you can add to your command & at the end to start it in the background.
To add to Greg's answer:
To run the Go App as a service you need to create a new service unit file.
However, the App needs to know where Go is installed. The easiest way to lookup that location is by running this command:
which go
which gives you an output like this:
/usr/local/go/bin/go
With this piece of information, you can create the systemd service file. Create a file named providus-app.service in the /etc/systemd/system/ using the command below:
sudo touch /etc/systemd/system/providus-app.service
Next open the newly created file:
sudo nano /etc/systemd/system/providus-app.service
Paste the following configuration into your service file:
[Unit]
Description=Providus App Service
After=network.target
[Service]
Type=forking
User=deploy
Group=deploy
ExecStart=/usr/local/go/bin/go run main.go
WorkingDirectory=/home/deploy/providus-app
Restart=always
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=providus-app-service
PrivateTmp=true
[Install]
WantedBy=multi-user.target
When you are finished, save and close the file.
Next, reload the systemd daemon so that it knows about our service file:
sudo systemctl daemon-reload
Start the Providus App service by typing:
sudo systemctl restart providus-app
Double-check that it started without errors by typing:
sudo systemctl status providus-app
And then enable the Providus App service file so that Providus App automatically starts at boot, that is, it can start on its own whenever the server restarts:
sudo systemctl enable providus-app
This creates a multi-user.target symlink in /etc/systemd/system/multi-user.target.wants/providus-app.service for the /etc/systemd/system/providus-app.service file that you created.
To check logs:
sudo journalctl -u providus-app