Kill is to kill. Given that nouns like “master” and “slave” need to be corrected in computer software, a word like “kill”, with its obvious negative connotations, should logically also need to be eliminated.
However, it might be better to change the name of the command. Because on Linux, kill doesn’t mean kill at all.
It just wants to send a signal to the process. Use kill -l to see a long list of signals.
The most popular one for Java programmers is kill -9, which I don’t know where it came from, but code farmers like this kind of violent command — like to kill with a sharp dagger.
But this is much more dangerous and doesn’t give progression a chance to speak.
Everyone knows that in TV dramas, when an important person dies, he will say something AD nauseam, and he won’t die until he can finish. Both martial arts masters and dignitaries have to give up some guff to keep the plot moving.
“Outlaws of the Marsh” in the “heroes”, to a relatively direct. See not happy, directly cut to the point, do not allow others to have a little nonsense, usually directly burp fart.
You use kill -9 brothers, all like black Li Kui, simple, violent, not human.
SIGKILL 9 Kill signal Indicates the end signalCopy the codeThe Chinese doctrine of tai Chi, the doctrine of the mean, is lost here. Kill -9 directly makes the term gracefully off obsolete.
What is graceful closure? In fact, it is like a person’s “last words”, to explain some things after death before death.
I used to think about spending all my money before I died. Neither to posterity, nor to rot in the bank. It takes a lot of work.
In computer software, there’s a lot to do before you die. For example, the contents of the buffer need to be processed and sent out; Microservice nodes need to remove themselves from the registry before they can rest assured to go die.
Generally speaking, it has the following effects:
- Lost request: Lost requests waiting to be executed in the memory queue
- Data loss: Data in the in-memory cache is not persisted to disk
- File corruption: The file being written is not updated, causing file corruption
- Service interruption: Half of the transaction is forcibly interrupted, for example, payment is successful without updating to the database
- Service not offline: The upstream service still sends requests to the stop node
Under these circumstances, if the service is broken, just be hit by the leader, be fired is a matter of minutes.
Java applications are full of this elegance, thanks to shutdownhook. Here’s the line:
Runtime
.getRuntime()
.addShutdownHook(
new Thread(() -> System.out.println("Do something in Shutdown Hook")));
Copy the codeIs there a good way? If yes, use kill -15 to send the SIGTERM signal.
But sometimes kill-15 doesn’t kill a process, and that’s where kill-9 comes in.
After hearing 15’s deathbed nonsense, use 9 to kill it.
In general, you need to use kill -15 to try to kill the process. If the process has not stopped after a certain amount of time (say, 10 seconds), kill -9 is introduced.
The default signal value for kill is 15, which is pretty sweet. But a lot of people still use 9.
I thought for a long time the reason, is a word: lazy.
Kill -15 requires multiple confirmations, whereas kill -9 is done once, and most of the time it is safe. Why not do something to improve work efficiency?
And SIGQUIT, which is kill -3.
In Java programs, the output of kill -3 is particularly interesting because it directly prints the output of the jStack command on stdout. If tomcat is used, the output is in the canalina.out file.
If JStack isn’t working for your application, or your application is barely responding. Using Kill-3 is a curvilinear way to save the nation.
The JDK blocks this signal, which is a bonus for Java. We can find this in the JDK documentation.
Sun’s JVM catches signals to implement shutdown hooks for abnormal JVM termination. The JVM uses SIGHUP, SIGINT, and SIGTERM to initiate the running of shutdown hooks.
The JVM uses a similar mechanism to implement The pre-1.2 feature of contracting thread stacks for debugging purposes. Sun’s JVM uses SIGQUIT to perform thread dumps.
I have a script here that takes two arguments. The first parameter is pid, and the second parameter is the number of seconds to wait.
pid=$1 count=$2 n=0 if [ ! -n $count ]; then count=10 fi while [[ $n -lt $count ]] do let "n++" kill -0 $pid if [ $? -ne 0 ] then echo "program not exist" break else echo "send kill -15 to $pid" kill -15 $pid sleep 1 fi if [[ $n -eq $count ]] then echo "kill -9 $pid" # after 10s , try to send kill -9 kill -9 $pid fi doneCopy the codeThe script continues to use kill -0 to determine whether the process exists, and then continues to send the kill -15 command. If the process still exists after the specified number of seconds, the kill -9 command is sent.
The problem is, you usually have to wait a few seconds. Automated robots don’t get bored. You do.
So you still use kill -9.