In a server that I'm working on, There are many apache processes running in background. Is it safe to kill all the processes? If so, please guide me the steps involved in it. I have seen 12 httpd commands running as per result of top command, hope it helps in debugging the problem.
You can kill httpd process using this command
sudo kill `pgrep httpd`
Source: https://www.cyberciti.biz/faq/kill-process-in-linux-or-terminate-a-process-in-unix-or-linux-systems/
OR
Stop the Apache service with:
sudo systemctl stop httpd.service
Prevent Apache from loading when the system boots:
sudo systemctl disable httpd.service
Source: https://phoenixnap.com/kb/how-to-restart-apache-centos-linux
Related
I ran into a problem when trying to build a watchdog for httpd.
The unit part of the systemd service file looks like this:
[Unit]
# Bindngs
BindsTo=httpd.service
# Startup
After=httpd.service
What happens is that the watchdog restarts on a
systemctl restart httpd
It also follows httpd and stops on a stop, but doesn't start when I start httpd after a stop. Desired behaviour is that the watchdog should follow httpd through all states and restart the device if httpd hangs or stops in an uncontrolled way. That functionality is in place, it's just the systemd stuff that puzzles me.
What should be in the service file to get the watchdog starting and stopping as I want?
I have a Python pyramid application that I am running using uwsgi like so:
sudo /finance/finance-env/bin/uwsgi --ini-paste-logged /finance/corefinance/production.ini
Once it's running and my window times out, I am unable to stop the server without rebooting the whole box. How do I stop the server?
You can kill uwsgi process using standard Linux commands:
killall uwsgi
or
# ps ax|grep uwsgi
12345
# kill -s QUIT 12345
The latter command allows you to do a graceful reload or immediately kill the whole stack depending on the signal you send.
The method you're using, however, is not normally used in production: normally you tell the OS to start your app on startup and to restart it if it crashes. Otherwise you're guaranteed a surprise one day at a least convenient time :) Uwsgi docs have examples of start scripts/jobs for Upstart/Systemd.
Also make sure you don't really run uwsgi as root - that sudo in the command makes me cringe, but I hope you have uid/gid options in your production.ini so Uwsgi changes the effective user on startup. Running a webserver as root is never a good idea.
If you add a --pidfile arg to the start command
sudo /finance/finance-env/bin/uwsgi --ini-paste-logged /finance/corefinance/production.ini --pidfile=/tmp/finance.pid
You can stop it with the following command
sudo /finance/finance-env/bin/uwsgi --stop /tmp/finance.pid
Also you can restart it with the following command
sudo /finance/finance-env/bin/uwsgi --reload /tmp/finance.pid
When I run dsc cassandra on CoreOS(tarball) using telnet everything comes up fine. But when i close the telnet session, it kills the process. How do i keep the cassandra server running?
I tried sudo bin/cassandra and sudo bin/cassandra -f
both didnt help.
I have no issues in other OS.
Option Description
-f Start the cassandra process in foreground. The default is to start as background process.
-h Help.
-p filename Log the process ID in the named file. Useful for stopping Cassandra by killing its PID.
-v Print the version and exit.
When you are starting cassandra using -f it runs in foreground, hence it will stop as soon as terminal is closed. Same is true for background process.
This will happen with any application you run in telnet session.
You can try
sudo service cassandra start OR nohup bin/cassandra this will keep your application running even when terminal is closed
You need to run Cassandra as a systemd service, as described here: https://coreos.com/os/docs/latest/getting-started-with-systemd.html
Running in the foreground with cassandra -f as your ExecStart= command will allow systemd to manage the state of the process (ideally inside a container).
While this is a bit different than what you're used to, it will lead to an overall more stable mechanism since you'll be using an init system that understands dependency chains, restart and reboot behavior, logging, etc.
Run the process in a screen or tmux session. Detaching from the screen session should allow the process to keep running.
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
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