I created upstart config file at: /etc/init/carbon-cache.conf to stop/start/restart carbon-cache process. I can start carbon-cache process using command: start carbon-cache, however, I could not use stop/restart carbon-cache and always gives me errors: "stop: Unknown instance:".
Does anyone know what seem to be the issue? Here is the my upstart config: /etc/init/carbon-cache.conf
description "Daemonized Carbon-Cache"
start on runlevel [2345]
stop on runlevel [016]
setuid www-data
setgid www-data
exec /opt/graphite/bin/carbon-cache.py start
respawn
respawn limit 10 5
I suggest using this carbon-cache.conf file: https://gist.github.com/dbeckham/8057390
i think what's happening is that your upstart is successfully able to exec it, but as soon as it runs, carbon-cache, because of it's daemonic nature detaches itself from upstart. So when upstart tries to kill it, it realizes that carbon-cache is no longer attached.
Upstart expects the command run to stay in the foreground, not fork-off and de-attach.
"Twistd, the utility used to daemonize carbon-cache supports a --nodaemon flag that launches the process in the foreground instead of forking it into the background. At the time this article was posted, the only way to get the --nodaemon flag to twistd was by starting carbon-cache with --debug."
Though, i'd advice against un-daemoning carbon, which is necessary in an upstart implementation.
sudo /opt/graphite/bin/carbon-cache.py start
Related
In my usecase, I am trying to write an upstart script for grafana service. Here is my content,
#grafana upstart script
description "start and stop grafana server"
start on (net-device-up
and local-filesystems
and runlevel [2345])
stop on runlevel [016]
respawn
respawn limit 5 30
console output
exec service grafana-server stop
But this is not woking all the time. Do I need remove any pid after stopping the service?
Also is this the right way to create upstart conf with service. Because I tried to do the same for nginx service. But it fails because we need to remove the pid after stopping the service.
So in general how can we write upstart script for services?
I am using amazon linux [ec2]. Could someone help me with this?
You can just look at any script in the folder /etc/init.d and change the instructions according your your needs. The you can use the systemctl (or the appropiate command for your distribution) to make it run on the desired init levels
My python source file automatically starts while I boot the system. I tried in init.d and some other shell scripts, but its not working. Note (I also make the executable file), but it doesn't work.
Please help.
There are a number of other posts covering this topic, notably here
Put this in /etc/init (Use /etc/systemd in Ubuntu 15.x)
mystartupscript.conf
start on runlevel [2345] stop on runlevel [!2345] exec /path/to/script.py
By placing this conf file there you hook into ubuntu's upstart service that runs services on startup.
manual starting/stopping is done withsudo service mystartupscript start and sudo service mystartupscript stop
There is another solution here also also
I have a script which is specified to start on boot-up with the #reboot annotation.
I tried to restart the script by stopping the cron daemon and starting it by entering service crond stop and service crond start, respectively.
However, I noticed that the script doesn't restart at the restarting of the cron daemon, but only when the entire system is rebooted.
My question is, since the cron daemon starts when the system is booted, is there a way start jobs not on reboot but specifically when the cron daemon starts so that service crond stop and service crond start work as expected?
Unfortunately, there is no way to do so,
Cron daemon just ignores #reboot directive
(CRON) INFO (Skipping #reboot jobs -- not system startup)
However, if you're trying to start some script at boot time and have ability to restart it without rebooting the machine, you might want to consider creating either init script or, if you're using systemd, systemd service description.(same with upstart and other init replacements)
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