Cassandra process killed on exit - cassandra

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.

Related

Redis Startup issues on Debian Stretch (9)

Actually I'm on my way to switch to debian 9 for the new production servers of the company and want to provision them with ansible. So far, everything works fine, but now I'm stuck with redis-server.
By default, Debian 9 comes with redis version 3.2. I'm installing the package via apt-get install redis-server. After that, redis starts up as a daemon in the background. Now I want to apply some custom configuration, like binding to 2 different IPs (127.0.0.1 and the server IP).
After changing this as well as the daemonize option (to yes), redis is no longer willing to start in the background. Whenever doing either service redis-server start or /etc/init.d/redis-server start, the command just stucks.
journalctl -xe tells me, that the pid file is not readable (redis-server.service: PID file /var/run/redis/redis-server.pid not readable (yet?) after start-post: No such file or directory) even though it should be created according to init.d script:
start)
echo -n "Starting $DESC: "
mkdir -p $RUNDIR
touch $PIDFILE
chown redis:redis $RUNDIR $PIDFILE
chmod 755 $RUNDIR
After all, I can see, that both service redis-server start and /etc/init.d/redis-server are starting the server and I'm also able to connect to the server via redis-cli. But the damn process stucks.
Can anyone help? If you need further information, just let me know. I'll provide what ever possible if this solves the problem!
best
Chris
I had a similar situation on a Centos 7 server.
The resolution was to change supervised from no to auto
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes
# If you run Redis from upstart or systemd, Redis can interact with your
# supervision tree. Options:
# supervised no - no supervision interaction
# supervised upstart - signal upstart by putting Redis into SIGSTOP mode
# supervised systemd - signal systemd by writing READY=1 to $NOTIFY_SOCKET
# supervised auto - detect upstart or systemd method based on
# UPSTART_JOB or NOTIFY_SOCKET environment variables
# Note: these supervision methods only signal "process is ready."
# They do not enable continuous liveness pings back to your supervisor.
supervised auto
When you run the process as daemon it need to interact with systemd for process management (if I read well some documentation).
Thanks

How do I stop a uWSGI server after starting it?

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

docker stop spark container from exiting

I know docker only listens to pid 1 and in case that pid exits (or turns into a daemon) it thinks the program exited and the container is shut down.
When apache-spark is started the ./start-master.sh script how can I kept the container running?
I do not think: while true; do sleep 1000; done is an appropriate solution.
E.g. I used command: sbin/start-master.sh to start the master. But it keeps shutting down.
How to keep it running when started with docker-compose?
As mentioned in "Use of Supervisor in docker", you could use phusion/baseimage-docker as a base image in which you can register scripts as "services".
The my_init script included in that image will take care of the exit signals management.
And the processes launched by start-master.sh would still be running.
Again, that supposes you are building your apache-spark image starting from phusion/baseimage-docker.
As commented by thaJeztah, using an existing image works too: gettyimages/spark/~/dockerfile/. Its default CMD will keep the container running.
Both options are cleaner than relying on a tail -f trick, which won't handle the kill/exit signals gracefully.
Here is another solution.
Create a file spark-env.sh with the following contents and copy it into the spark conf directory.
SPARK_NO_DAEMONIZE=true
If your CMD in the Dockerfile looks like this:
CMD ["/spark/sbin/start-master.sh"]
the container will not exit.
tail -f -n 50 /path/to/spark/logfile
This will keep the container alive and also provide useful info if you run -it interactive mode. You can run -d detached and it will stay alive.

Centos 7: Auto restart application if it stopped

I want to auto restart my application "Fiware IoT Agent" if it stopped, the problem is that it depends of Mongo Db Data Base and the Mosquitto broker. My OS is centOS 7
Here is the commands that I use to launch my three application in the following order:
*Mongo:
/usr/local/iot/mongodb-linux-x86_64-3.0.5/bin/mongod --dbpath /usr/local/iot/mongodb-linux-x86_64-3.0.5/data/db$
*Mosquitto broker
/usr/sbin/mosquitto -c /etc/iot/mosquitto.conf &
pid=$!
echo $pid > /var/run/iot/mosquitto.pid
Iot Agent:
than I start my application using this command
export LD_LIBRARY_PATH=/usr/local/iot/lib
/usr/local/iot/bin/iotagent -i 192.168.1.11 -p 80 -v DEBUG -d /usr/local/iot/lib -c /etc/iot/config.json
how can I start my application if it stopped known that it depends of the other two application? If for example Mongo DB stopped, I must be able to restart it and then to restart my application.
CentOS 7 uses systemd. You can create systemd service for each of your applications and specify dependencies between them. And specify "Restart=always" for service which need to be auto restarted.
You can create your own watch dog code. When you start your application get the pid of the process and the pid of mongo DB.
Every couple of second like 10 seconds check that the pid of both process still exist, or you can also make the programs touch a file every couple of seconds as well then check the file modification time to see if the programs are still alive.
If the program hasn't touched the file or if you go jus the pid route and the pid doesn't exist. Then the program has died.
Restart the program and get the new pid and go about again in a forever while loop.

How to run node.js app forever when console is closed?

I connect to my remote server via ssh. Then I start my node.js app with Forever. Everything works fine until I close my console window. How to run node.js app FOREVER on my remote server even when I close my connection via ssh? I just want to start an app and shut down my copmputer. My app should be working in the background on my remote server.
You may also want to consider using the upstart utility. It will allow you to start, stop and restart you node application like a service. Upstart can configured to automatically restart your application if it crashes.
Install upstart:
sudo apt-get install upstart
Create a simple script for your application that will look something like:
#!upstart
description "my app"
start on started mountall
stop on shutdown
# Automatically Respawn:
respawn
respawn limit 99 5
env NODE_ENV=production
exec node /somepath/myapp/app.js >> /var/log/myapp.log 2>&1
Then copy the script file (myapp.conf) to /etc/init and make sure its marked as executable. Your application can then be managed using the following commands:
sudo start myapp
sudo stop myapp
sudo restart myapp
Two answers: One for Windows, one for *nix:
On Windows, you can use the start command to start the process disconnected from your instance of cmd.exe:
start node example.js
On *nix, there are two aspects of this: Disconnecting the process from the console, and making sure it doesn't receive the HUP signal ("hang up"), which most processes (including Node) will respond to by terminating. The former is possibly optional, but the latter is necessary.
Starting disconnected from the console is easy: Usually, you just put an ampersand (&) at the end of the command line:
# Keep reading, don't just grab this and use it
node example.js &
But the above doesn't protect the process from HUP signals. The program may or may not receive HUP when you close the shell (console), depending on a shell option called huponexit. If huponexit is true, the process will receive HUP when the shell exits and will presumably terminate.
huponexit defaults to false on the various Linux variants I've used, and in fact I happily used the above for years until coderjoe and others helped me understand (in a very long comment stream under the answer that may have since been deleted) that I was relying on huponexit being false.
To avoid the possibility that huponexit might be true in your environment, explicitly use nohup. nohup runs the process immune from HUP signals. You use it like this:
nohup node example.js > /dev/null &
or
nohup node example.js > your-desired-filename-or-stream-here &
The redirection is important; if you don't do it, you'll end up with a nohup.out file containing the output from stdout and stderr. (By default, nohup redirects stderr to stdout, and if stdout is outputting to a terminal, it redirects that to nohup.out. nohup also redirects stdin if it's receiving from a terminal, so we don't have to do that. See man nohup or info coreutils 'nohup invocation' for details.)
In general for these things, you want to use a process monitor so that if the process crashes for some reason, the monitor restarts it, but the above does work for simple cases.
I would definitely recommend pm2
npm install -g pm2
To start server: pm2 start [yourServerFile.js]
To stop server: pm2 stop [yourServerFile.js]
Close client and server will run forever....will also restart if app crashes.
Ive been running a node server on Ubuntu for months with zero issues
Always, simple is the best, no need upstart, no need forever, just nohup:
nohup node file.js &
Believe me, I'm running so that for my case!
You could install forever using npm like this:
sudo npm install -g forever
Or as a service:
forever start server.js
Or stop service
forever stop server.js
To list all running processes:
forever list
node expamle.js & for example
In Linux, SSH into your remote server and run
screen
to launch into a new screen.
Finally, type ctrlad to detach the screen session without killing the process.
More info here.
I had similar issue and I think using forever will help to handle crashed and restarts
You can install forever globally:
sudo nom install -g forever
And run this command:
nohup forever server.js &
This should handle all the trouble of closing the terminal, closing ssh session, node crashes and restarts.
If you're running node.js in a production environment, you should consider using PM2, forever.js, or Nodemon.
There is no shortage of articles online comparing the different packages.
This is only a partial answer for Windows. I’ve created a single line Visual Basic Script called app.vbs that will start your node application within a hidden window:
CreateObject("Wscript.Shell").Run "node app.js", 0
To execute it automatically at startup, open the %AppData%\Microsoft\Windows\Start Menu\Programs\Startup\ directory and add a shortcut to the app.vbs file.
More info at: https://keestalkstech.com/2016/07/start-nodejs-app-windowless-windows/
Wow, I just found a very simple solution:
First, start your process (node app)
forever dist/index.js
run: ^Z cmd + z.
Then: bg. Yeah.. bg (background).
And pum.. you are out.
Finish with exitif you are with sshor just close the terminal.
my start.sh file:
#/bin/bash
nohup forever -c php artisan your:command >>storage/logs/yourcommand.log 2>&1 &
There is one important thing only. FIRST COMMAND MUST BE "nohup", second command must be "forever" and "-c" parameter is forever's param, "2>&1 &" area is for "nohup". After running this line then you can logout from your terminal, relogin and run "forever restartall" voilaa... You can restart and you can be sure that if script halts then forever will restart it.
I <3 forever

Resources