I'm writing a script to start Jboss, load an application, send requests to the application, shutdown jboss and repeat. However I dont know how to shut Jboss down from the script. At the moment I'm using
pkill -9 java
But I dont think this is right, because it kills the process, not shut it down. Is there a way to shut it down similar to pressing CTRL-C?
You want a simple
pkill java
From the man page:
pkill will send the specified signal (by default SIGTERM) to each
process
SIGTERM will send a termination signal to the process. If the process is well-written, it will catch this signal and perform an orderly shutdown. If that fails, that's when you can use SIGKILL (-9) which is a forceable termination with no chance for the process to catch and perform cleanup.
Never use kill -9 <PID> by default. It breaks things up, like file descriptors and such.
Start to run kill <PID> alone, default is -15 signal.
See
man 7 signal
And In what order should I send signals to gracefully shutdown processes?
NOTE
kill or pkill doesn't change things so much, same signals are trigered
What you actually want is:
pkill -f jboss
using pkill java could kill any other processes using java on the box.
Related
I am using a systemd service which calls a process when it's been "started" (e.g. systemctl start test.service). As per the design, the process stays in a loop forever, we are able to see process existence using the ps command. We have also seen that the process is getting killed (as intended) for systemctl stop command.
However, our requirement is that we want to do some safe shutdown operations from within the process before it gets killed. But I am not sure how to detect a systemd stop operation from within the process.
Does a systemctl stop test.service command send SIGKILL or SIGTERM signal to kill the process? How can I detect a systemctl stop operation from within a process?
By default, a SIGTERM is sent, followed by 90 seconds of waiting followed by a SIGKILL.
Killing processes with systemd is very customizable and well-documented.
I recommend reading all of man systemd.kill as well as reading about ExecStop= in man systemd.service.
To respond to those signals, refer to the signal handling documentation for the language you are using.
Does a systemctl stop test.service command send SIGKILL or SIGTERM signal to kill the
process? How can i detect a systemctl stop operation from within a process?
Systemd sends SIGTERM signal to process. In process you have to register signals, which are "caught".
In process, eg. SIGTERM signal can be registered like this:
void signal_callback()
{
printf("Process is going down\n");
}
signal(SIGTERM, signal_callback)
When SIGTERM is sent to the process, the signal_callback() function is executed.
with an unprivileged user account, using bash, I could do:
sudo /bin/sleep 6000
and kill it with Ctrl-c. However, sending SIGINT or SIGKILL from another terminal won't work for that purpose.
Anyone knows why is that? I'd like to be able to kill the process sending a signal, for using in a script, for example.
Regards.
You're only allowed to send signals to a process running with the same UID (unless the sending process is running as root). When you use sudo, the new process is running as root, but if you try to kill it you're running as your normal userid. You would have to use sudo kill PID to kill it.
Signals sent from terminal control characters are treated specially: they can be sent to any process running in the same login session as the terminal.
On a linux box, I have at most 3 java jars files running. How do I quickly kill all 3 with one command?
Usually I would:
ps ex - get the processes running
then find the process ids then do:
kill -9 #### #### ####
Any way to shorten this process? My eyes hurts from squinting to find the process ids.
My script does the following:
nohup ./start-gossip &
nohup ./start &
nohup ./start-admin &
Is there a way to get the process ids of each without looking it up?
Short answer:
pkill java
This looks up a process (or processes) to kill by name. This will find any other java processes too, so be careful. It also accepts -9, but you should avoid using -9 unless something is really broken.
EDIT:
Based on updates, you may be able to specify the script names to pkill as well (I'm not positive). But, the more traditional way to handle this issue is to leave pid files around. After you start a new process and background it, its pid is available in $!. If you write that pid to a file, then it's easy to check if the process is still running and kill just the processes you mean to. There is some chance that the pid will be reused, however.
You can save the PIDs when you start the processes so you can use them later:
nohup ./start-gossip &
START_GOSSIP_PID=$!
nohup ./start &
START_PID=$!
nohup ./start-admin &
START_ADMIN_PID=$!
...
kill -9 $START_GOSSIP_PID
kill -9 $START_PID
kill -9 $START_ADMIN_PID
This has the advantage (over pkill) of not killing off any other processes that coincidentally have similar names. If you don't want to perform the kill operation from the script itself, but just want to have the PIDs handy, write them to a file (from the script):
echo $START_GOSSIP_PID > /some/path/start_gossip.pid
Or even just do this when you launch the process, rather than saving the PID to a variable:
nohup ./start-gossip &
echo $! > /some/path/start_gossip.pid
To get the process id of that java process run
netstat -tuplen
Process ID (PID) of that process whom you want to kill and run
kill -9 PID
I have a script which does launch another application using nohup my_app &, but when the initial script dies the launched process also goes down. As per my understanding since since it has been ran with nohup that should not happen. The original script also called with nohup.
What went wrong there?
A very reliable script that has been used successfully for years, and has always terminated after invoking a nohup uses this construct:
nohup ${BinDir}/${Watcher} >${DataDir}/${Watcher}.nohup.out 2>&1 &
Perhaps the problem is that output is not being managed?
nohup does not mean that a (child) process is still running when the (parent) process is killed. nohup is used f.e. when you're connecting over ssh to a server and there starting a process. If you log out, the process will terminate (logging out sents the signal SIGHUP to the process causing the process to terminate), using nohup avoid this behaviour and you're process is still running when you logged out.
If you need a program which runs in the background even it's parent process has terminated try using daemons.
It depends what my-app does - it might set its own signal mask. You probably know that nohup ignores the hang-up signal SIGHUP, and this is inherited by the target program. If that target program does its own signal handling then it might be setting SIGHUP to, for example SIG_DFT - the default action (which is to die).
To check, run strace -f -o out or truss -f -o out on the command. This will give you all the kernel calls in the file called 'out'. You should be able to spot the signal mask being changed if it is.
If I am working on a remote server (ssh) and I fork a process using bash & operator, will that process be killed if I am booted off the server due to server time-out? I'm pretty sure the answer is yes, but would love to know if there are any juicy details.
It might depend, but generally when you log out with your "connection program" (e.g. ssh in your case although it could have been rlogin or telnet as well), the shell and children (I think?) will receive a SIGHUP signal (hangup) which will make them terminate when you log out. There are two common ways to avoid this, running the program you want to keep running through nohup or screen. If the server have some other time limitation on running processes you will have to look into that.
bash will send a HUP signal to all background jobs. You can stop this from happening by starting the job with nohup (which should have a man page). If it's too late for nohup, you can use disown to stop the shell from sending a HUP to a job. disown is a builtin, so help disown will tell you everything you need to know.