Shulou(Shulou.com)06/01 Report--

This article mainly introduces how to solve the problem of abnormal exit of tomcat caused by semaphores. It is very detailed and has a certain reference value. Interested friends must read it!

I have been playing big data recently. A friend came over and said that his online tomcat would quit inexplicably, saying that he was very upset. Let me take a look at it. Every time he finds that he has exited, he logs in through Tencent Cloud's WEB console and starts tomcat.

In the spirit of helping others (shao kao hao chi), I joined up and began to analyze. First of all, be sure to look at the tomcat log to see if any relevant information has been recorded and what is the way to exit.

From the log, tomcat received an exit request and closed the container as required. So is it possible to assume that someone executed the shutdown.sh? Not really. The shutdown log that executes the shutdown script looks like this.

The screenshot of the tomcat source code associated with it is as follows. There is a line number on the left side of the screenshot.

When tomcat starts, set await and wait for the shutdown instruction to enter. Org\ apache\ catalina\ startup\ Bootstrap.java

CatalinaDaemon is defined as follows.

Org\ apache\ catalina\ startup\ Catalina.java

When specifically instantiated, an instance of the interface Server is pointed to StandardServer. The classpath is as follows.

Org\ apache\ catalina\ Server.java

Org\ apache\ catalina\ core\ StandardServer.java

The source code of the output related log in StandServer is as follows:

The configuration file read is org\ apache\ catalina\ core\ LocalStrings.properties

When tomcat receives a serious shutdown instruction, it outputs this log, indicating that it has received an instruction to close the container.

Serious instructions to close the container, the related code is as follows.

So, the evidence now suggests that the tomcat was not shut down through a SHUTDOWN message. And, from the picture below, it shows that this SHUTDOWN instruction is not so easy to send successfully.

So now the most likely way is to operate through the KILL instruction. You need to log in to the machine to execute the bash script, so what about looking up the login records at this point in time from wtmp and utmp?

Here are the results of IPIP.

In other words, when tomcat exited abnormally on the morning of the 23rd, an address from Tencent Cloud's BGP server room also coincidentally disconnected the session. And my friend's machine is on Tencent Cloud. It's a little weird, isn't it?

Continue to trace, trace back to the tomcat log for several days, compare the utmp and wtmp results, and then compare the IPIP results. The session from Tencent Cloud BGP server room is disconnected and tomcat exits at the same time. Accurate to seconds. There are many times in many days, indicating that there is a causal relationship between tomcat exit and WEB session exit.

After questioning, the friend confirmed that he was accustomed to using the WEB console to log on to the server. After starting tomcat, he threw it aside and began to debug the interface. So what could lead to such a causal relationship? This is to talk about semaphores, a long-standing mechanism of inter-process communication in Linux systems.

What is the specific semaphore, please check the relevant information to learn. In view of this problem, it can be simply understood as a mechanism of inter-process communication.

Process A requires process B to do something, and the memory areas between processes are in a sense invisible to each other. At this time, it needs to be done through semaphores. Process A can send a semaphore to process B according to the predefined semaphore specification, and when process B receives it, the processing logic is determined according to the value of the specific semaphore. The specific semaphore list can be queried on the command line through the following command. There are all letters in the command, and there is no number 1.

One of the most common of these is 9MagneSIGKILL. When the process receives this semaphore, it will be dropped by KILL. This semaphore is processed by the operating system and cannot be processed by the application. In the pre-vista windows system, there was a way to infiltrate the kernel. At this point, you can intercept messages such as WM_CLOSE, so that a program cannot be closed. In the era of win7 and win10, such techniques can no longer be used.

In addition, the CTRL + C operation that we are familiar with emits SIGINT. In some scenarios, when we need to notify the program to exit gracefully, we can issue SIGQUIT, that is, kill-3.

So what semaphore will be emitted when the WEB console session is disconnected? Let's try and find out. Although Java can't operate at the bottom of the operating system, there are surprises in the sun.misc package. The code is as follows.

As shown in the figure, this code outputs the thread name, semaphore name, and translates it into a specific number when it receives the semaphore. Then, in the main function, I "registered" four semaphores: HUP, INT, ABRT, and TERM. Register four because you don't know exactly what will come out, so it's possible to do all of them.

Compile, package. There is a problem to note here. Because semaphores belong to the underlying mechanism of the operating system, the semaphores supported by different operating systems are different, which is supported by private static native int findSignal (String paramString) in JVM. The native method involves a specific VM implementation and does not post code. But it's easy to think that windows and linux are certainly different. So here it is written on the upper computer and debugged on the lower computer. Don't panic when you report an error when running under windows.

The next thing is simple. Upload the program to the server, log in to the server through the WEB console, redirect the execution result to a text file, and then wait for the console to time out. The results are as follows.

The result doesn't need to be analyzed any more, the WEB console issues SIGHUP on exit, which is equivalent to kill-1. What will tomcat do when he receives the SIGHUP? Friends can try kill-1 pid, and then look at the log, you will understand.

The solution is actually simple. SIGHUP means HANG UP, and you can use nohup xx.sh & to completely block SIGHUP and SIGINT. In addition, after testing, it is found that the semaphore can also be triggered by clicking the x on the right side of the tab page of SecureCRT, but not by directly logout or clicking the red cross on the menu.

Interested partners can extend this program and test it. Maybe your abnormal exit problem can be easily solved.

The above is all the contents of this article entitled "how to solve the problem of abnormal exit of tomcat caused by semaphores". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.