So I created a service and made it executale in /etc/init.d
Then I tried to make it start after boot with the following command:
update-rc.d <myService> defaults
But the output were warnings of other services (which work just fine by the way) and I don't want to touch those.
My next attempt to solve this was to add the following lines in the rc.local file:
do_start() {
service <someOtherService> stop
service <myService> stop
sleep 5
service <someOtherService> start
service <myService> stop
........
As I said, I have some other service that works just fine, but my service which I am currently trying to add wont start after boot.
One more thing that I would like to add is when I manually enter:
service <myService> start/stop
then it works just fine
To add a service at boot, you can add an Upstart job.
Create your conf file in /etc/init (e.g. /etc/init/myjob.conf)
with a content like this (Example)
description "My job"
start on startup
task
exec /path/to/script.sh
More informations here (Debian doc)
Info: you need the upstart package.
The following works very well for me.
First determine if your system is running SysV init or systemd, for that use:
$ ps -p 1
If SysV init:
$ sudo update-rc.d <service_name> defaults 95 10
If systemd:
$ sudo /bin/systemctl daemon-reload
$ sudo /bin/systemctl enable <service_name>.service
I successfully used the last one on a ParrotSecurity OS that is based on Debian 5.
Related
I have a simple script
#!/usr/bin/env python
# coding: utf-8
i=0
while (True):
print(i)
i=i+1
I want this script to run in background
If the server crashes, I want it to automatically restart an pick where the program left of
How do I do that
You have tu run your script as a service:
The file must have .service extension under /lib/systemd/system/ directory.
Now Your system service has been added to your service. Let’s reload the systemctl daemon to read new file. You need to reload this deamon each time after making any changes in in .service file.
sudo systemctl daemon-reload
Now enable the service to start on system boot, also start the service using the following commands.
sudo systemctl enable dummy.service
sudo systemctl start dummy.service
I personally use supervisord to handle processes. To make your script start where it left off you need some kind of persistence, like a file or a database where you can put the last state of your script and read at the restart.
So today one of our application servers were restarted due to some issue and after restart we found that our application services were not running.
I want to create one script which will check these below services after a server restart and start them automatically if found stopped:
1st Service with Path : /opt/bea/config/nm/nm-sdi-abc/beaNMctl.sh
2nd service TOMCAT - Path : /opt/apache/tomcat/bin --- Service name startup.sh
Catch here is 1st service can be started with the normal id account that i use.
But 2nd service can be restarted after logging into a different service account on same server and network. Like below:
[x201691#abc bin]$ su - apache
Password:
-bash-2.05b$ cd /
-bash-2.05b$ cd /opt/apache/tomcat/bin/
-bash-2.05b$ ./startup.sh
Can someone help?
Also we are not root users.
You can write a shell script:
echo YOUR_PASSWORD | sudo -S su
cd /opt/apache/tomcat/bin/
./startup.sh
Save this as a file somewhere you have access and add the following cron entry:
#reboot MYPATH/myscript.sh >> MYPATH/script.log 2>&1
script.log will contain any output or errors from your script. You can add date command to the script to help with information on when it was run. More information on cron here.
Also, if you have concern with putting password in the script, you can go through the discussion here.
Preferred approach when installing Tomcat in Linux is to make Tomcat as a service.
This will ensure your service is started after reboot
1. Create the service file with the following command:
touch /etc/systemd/system/tomcat.service
2. Assign the relevant rights to the file you created:
chmod 664 /etc/systemd/system/tomcat.service
3. Paste the following content in the file while adapting it to your configuration:
[Unit]
Description=Application description/name
After=syslog.target network.target
[Service]
Type=forking
User=tomcat
ExecStart=$CATALINA_HOME/bin/startup.sh
ExecStop=/bin/kill -15 $MAINPID
Install]
WantedBy=multi-user.target
4. Reload the service daemon:
systemctl daemon-reload
5. Start the service:
systemctl start tomcat
6. To check status :
systemctl status tomcat
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
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
Is there a brief guide to explain how to start up a application when the instance starts up and running? If it were one of the services installed through yum then I guess I can use /sbin/chkconfig to add it to the service. (To make it sure, is it correct?)
However, I just want to run the program which was not installed through yum. To run node.js program, I will have to run script sudo node app.js at home directory whenever the system boots up.
I am not used to Amazon Linux AMI so I am having little trouble finding a 'right' way to run some script automatically on every boot.
Is there an elegant way to do this?
One way is to create an upstart job. That way your app will start once Linux loads, will restart automatically if it crashes, and you can start / stop / restart it by sudo start yourapp / sudo stop yourapp / sudo restart yourapp.
Here are beginning steps:
1) Install upstart utility (may be pre-installed if you use a standard Amazon Linux AMI):
sudo yum install upstart
For Ubuntu:
sudo apt-get install upstart
2) Create upstart script for your node app:
in /etc/init add file yourappname.conf with the following lines of code:
#!upstart
description "your app name"
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
env NODE_ENV=development
# Warning: this runs node as root user, which is a security risk
# in many scenarios, but upstart-ing a process as a non-root user
# is outside the scope of this question
exec node /path_to_your_app/app.js >> /var/log/yourappname.log 2>&1
3) start your app by sudo start yourappname
You can use forever-service for provisioning node script as a service and automatically starting during boots. Following commands will do the needful,
npm install -g forever-service
forever-service install test
This will provision app.js in the current directory as a service via forever. The service will automatically restart every time system is restarted. Also when stopped it will attempt a graceful stop. This script provisions the logrotate script as well.
Github url: https://github.com/zapty/forever-service
As of now forever-service supports Amazon Linux, CentOS, Redhat support for other Linux distro, Mac and Windows are in works..
NOTE: I am the author of forever-service.
Quick solution for you would be to start your app from /etc/rc.local ; just add your command there.
But if you want to go the elegant way, you'll have to package your application in a rpm file,
have a startup script that goes in /etc/rc.d so that you can use chkconfig on your app, then install the rpm on your instance.
Maybe this or this help. (or just google for "creating rpm packages")
My Amazon Linux instance runs on Ubuntu, and I used systemd to set it up.
First you need to create a <servicename>.service file. (in my case cloudyleela.service)
sudo nano /lib/systemd/system/cloudyleela.service
Type the following in this file:
[Unit]
Description=cloudy leela
Documentation=http://documentation.domain.com
After=network.target
[Service]
Type=simple
TimeoutSec=0
User=ubuntu
ExecStart=/usr/bin/node /home/ubuntu/server.js
Restart=on-failure
[Install]
WantedBy=multi-user.target
In this application the node application is started. You will need a full path here. I configured that the application should simply restart if something goes wrong. The instances that Amazon uses have no passwords for their users by default.
Reload the file from disk, and then you can start your service. You need to enable it to make it active as a service, which automatically launches at startup.
ubuntu#ip-172-31-21-195:~$ sudo systemctl daemon-reload
ubuntu#ip-172-31-21-195:~$ sudo systemctl start cloudyleela
ubuntu#ip-172-31-21-195:~$ sudo systemctl enable cloudyleela
Created symlink /etc/systemd/system/multi-user.target.wants/cloudyleela.service → /lib/systemd/system/cloudyleela.service.
ubuntu#ip-172-31-21-195:~$
A great systemd for node.js tutorial is available here.
If you run a webserver:
You probably will have some issues running your webserver on port 80. And the easiest solution, is actually to run your webserver on a different port (e.g. 4200) and then to redirect that port to port 80. You can accomplish this with the following command:
sudo iptables -t nat -A PREROUTING -i -p tcp --dport 80 -j REDIRECT --to-port 4200
Unfortunately, this is not persistent, so you have to repeat it whenever your server restarts. A better approach is to also include this command in our service script:
ExecStartPre to add the port forwarding
ExecStopPost to remove the port forwarding
PermissionStartOnly to do this with sudo power
So, something like this:
[Service]
...
PermissionsStartOnly=true
ExecStartPre=/sbin/iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 4200
ExecStopPost=/sbin/iptables -t nat -D PREROUTING -p tcp --dport 80 -j REDIRECT --to-port 4200
Don't forget to reload and restart your service:
[ec2-user#ip-172-31-39-212 system]$ sudo systemctl daemon-reload
[ec2-user#ip-172-31-39-212 system]$ sudo systemctl stop cloudyleela
[ec2-user#ip-172-31-39-212 system]$ sudo systemctl start cloudyleela
[ec2-user#ip-172-31-39-212 system]$
For microservices (update on Dec 2020)
The previously mentioned solution gives a lot of flexibility, but it does take some time to set it up. And for each additional application, you need to go through this entire process again. By the time you'll be installing your 5th node application, you'll certainly start wondering: "there has to be a shortcut".
The advantage of PM2 is that it's just 1 service to install. Next it's PM2 which manages the actual applications.
Even the initial setup of PM2 is easy, because it automatically installs the pm2 service for you.
npm install pm2 -g
And adding new services is even easier:
pm2 start index.js --name "foo"`.
When everything's up and running, you can save your setup, to have it automatically start on reboot.
pm2 save
If you want an overview of all your running node applications,
you can run pm2 list
And PM2 also offers an online (webbased) dashboard to monitor your application remotely. You may need a license to access some of the dashboard functionality though (which is a bit over-priced imho).
You can create a script that can start and stop your app and place it in /etc/init.d; make the script adhere to chkconfig's conventions (below), and then use chkconfig to set it to start when other services are started.
You can pick an existing script from /etc/init.d to use as an example; this article describes the requirements, which are basically:
An executable script that identifies the shell needed (i.e., #!/bin/bash)
A comment of the form # chkconfig: where is often 345, startprio indicates where in the order of services to start, and stopprio is where in the order of services to stop. I generally pick a similar service that already exists and use that as a guide for these values (i.e., if you have a web-related service, start at the same levels as httpd, with similar start and stop priorities).
Once your script is set up, you can use
chkconfig --add yourscript
chkconfig yourscript on
and you should be good to go. (Some distros may require you to manually symlink to the script to /etc/init.d/rc.d, but I believe your AWS distro will do that for you when you enable the script.
Use Elastic Beanstalk :) Provides support for auto-scaling, SSL termination, blue/green deployments, etc
If you want the salty sysadmin way for a RedHat based linux distro (Amazon Linux is a flavor of RedHat), learn systemd, as mentioned by #bvdb in the answer above:
https://en.wikipedia.org/wiki/Systemd
Set everything up as described on an EC2 instance, snapshot a custom AMI, and use this custom AMI as your base for EC2 instances hosting your apps. This way you don't have to go through all that setup multiple times. You'll probably want to get acquainted with load balancers too, if you are running in a production environment with uptime requirements.
Or, yes, as mentioned by #bvdb, you could also use pm2 to interface with systemd. Though I don't think pm2 helps with running your app across multiple EC2 instances, which is definitely recommended for production environments with uptime requirements.
All of which is a very steep learning curve. Since the OP seemed to be new to all this, Elastic Beanstalk, Google App Engine, and others are a great way to get code running in the cloud without all that.
These days I dev in TypeScript, deploying to serverless function execution in the cloud for most things, and don't have to think about package installs or app startup at all.
You can use screen. Run crontab -e and add this line:
#reboot screen -d -m bash -c "cd /home/user/yourapp/; node app"
Have been using forever on AWS and it does a good job. Install using
[sudo] npm install forever -g
To add an application use
forever start path_to_application
and to stop the application use
forever stop path_to_application
This is a useful article that helped me with setting it up.