Restart identification method, device and equipment and computer readable storage medium

Abstract

The invention discloses a restart identification method, device and equipment and a computer readable storage medium, and is applied to the field of servers, and the method comprises the following steps: when a server is restarted, determining whether the server is normally restarted or not; if the server is normally restarted, sending a normal restart identifier to the controller; if the server is abnormally restarted, capturing system operation data in real time, and sending the system operation data and an abnormal restart identifier to the controller; the system operation data at least comprises register information and kernel stack information. According to the method and the device, the problem that the restart reason cannot be known when the restart event occurs in the server is solved. By setting the corresponding restart identifier, the controller can timely know whether the restart event of the server is normal restart or abnormal restart so as to give a prompt.

Description

Technical Field

[0001] The present invention relates to the field of servers, and in particular to a restart identification method, device, equipment and a computer-readable storage medium. Background Art

[0002] In server management practice, although users can learn about server restart events through the baseboard management controller (BMC), the user side cannot distinguish whether the restart is due to normal system maintenance operations or abnormal restarts caused by system downtime based on the BMC. As a result, users cannot know the real reason behind the restart and cannot make correct decisions.

[0003] Therefore, how to obtain the restart reason of the server restart event is a technical problem that urgently needs to be solved. Summary of the invention

[0004] In view of this, an object of the present invention is to provide a restart identification method, device, equipment and computer-readable storage medium, which solves the problem in the prior art that the controller cannot know the reason for the server restart.

[0005] In order to solve the above technical problems, the present invention provides a restart identification method, comprising:

[0006] When the server is restarted, determining whether the server is restarted normally;

[0007] If the server is restarted normally, a normal restart identifier is sent to the controller;

[0008] If the server is restarted abnormally, system operation data is captured in real time, and the system operation data and the abnormal restart identifier are sent to the controller; the system operation data at least includes register information and kernel stack information.

[0009] On the one hand, if the server is restarted normally, sending a normal restart identifier to the controller includes:

[0010] If the server restarts normally due to a system maintenance operation, a normal restart instruction is executed, and the normal restart instruction includes a restart instruction and a normal restart flag sending instruction; the normal restart flag sending instruction sends the normal restart flag to the controller through a command line tool or an out-of-band management framework.

[0011] On the one hand, if the server is restarted abnormally, capturing system operation data in real time, and sending the system operation data and an abnormal restart identifier to the controller, including:

[0012] When the server experiences a system crash, it will automatically trigger an abnormal restart of the kernel crash dump mechanism, and execute a pre-configured first script, which includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a system operation data sending instruction and a restart instruction.

[0013] On the one hand, if the server is restarted abnormally, capturing system operation data in real time, and sending the system operation data and an abnormal restart identifier to the controller, including:

[0014] When the server experiences a system crash, an abnormal restart of the kernel crash dump mechanism is automatically triggered, and a pre-configured second script is executed, wherein the second script includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a restart instruction, and a memory dump file identification instruction;

[0015] The memory transfer file identification instruction includes:

[0016] If the kernel crash dump mechanism is triggered normally, a memory dump file is successfully generated, and a kernel crash dump mechanism success mark sending instruction, a memory dump file sending instruction, and a kernel restart mark sending instruction are triggered;

[0017] If the kernel crash dump mechanism is not triggered normally, the memory dump file generation fails, and a kernel crash dump mechanism failure identification sending instruction, a system operation data sending instruction, and a kernel restart identification sending instruction are triggered.

[0018] On the one hand, triggering the memory transfer file sending instruction includes:

[0019] Before executing the restart instruction, the memory dump file is obtained by calling the kdump_post parameter, and the register information and the kernel stack information in the memory dump file are sent to the controller.

[0020] On the one hand, triggering the system to run a data sending instruction includes:

[0021] Before executing the restart instruction, the system operation data is extracted from the dmesg log and sent to the controller.

[0022] On the one hand, sending the system operation data and the abnormal restart mark to the controller includes:

[0023] The system operation data and the abnormal restart identifier are sent to the controller through a command line tool or an out-of-band management framework, displayed on the controller, and recorded item by item in the event log of the server.

[0024] The present invention also provides a restart identification device, comprising:

[0025] A restart mode determination module, used to determine whether the server is restarted normally when the server is restarted;

[0026] A normal restart module, configured to send a normal restart identifier to the controller if the server is restarted normally;

[0027] The abnormal restart module is used to capture system operation data in real time if the server is restarted abnormally, and send the system operation data and the abnormal restart identifier to the controller; the system operation data at least includes register information and kernel stack information.

[0028] The present invention also provides a restart identification device, comprising:

[0029] Memory for storing computer programs;

[0030] A processor is used to implement the steps of the above-mentioned restart identification method when executing the computer program.

[0031] The present invention also provides a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the steps of the above-mentioned restart identification method are implemented.

[0032] The present invention also provides a computer program product, including a computer program / instruction, which implements the steps of the above-mentioned restart identification method when executed by a processor.

[0033] It can be seen from the above technical solution that the present invention determines whether the server is restarted normally when the server is restarted; if the server is restarted normally, a normal restart mark is sent to the controller; if the server is restarted abnormally, the system operation data is captured in real time, and the system operation data and the abnormal restart mark are sent to the controller; the system operation data at least includes register information and kernel stack information. The beneficial effect of the present invention is that by strengthening the server system function, the server can send a corresponding restart mark to the controller according to the restart situation, and the controller's monitoring ability of the server is enhanced, so that it can monitor the health status of the server in real time, and the system administrator can directly know the reason for the server restart, so as to further analyze the health status of the server according to the restart reason, and make corresponding decisions in time when abnormal. This provides a valuable time window for system administrators to respond quickly and take measures.

[0034] In addition, the present invention also provides a restart identification device, equipment and computer-readable storage medium, which also have the above-mentioned beneficial effects. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0036] Figure 1 A flowchart of a restart identification method provided by an embodiment of the present invention;

[0037] Figure 2 An example flowchart of a restart identification method provided by an embodiment of the present invention;

[0038] Figure 3 A schematic diagram of the structure of a restart identification device provided by an embodiment of the present invention;

[0039] Figure 4 A schematic diagram of the structure of a restart identification device provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0040] In order to make the purpose, technical solution and advantages of the embodiments of the present invention clearer, the technical solution in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0041] First, several nouns involved in the present invention are analyzed:

[0042] Kdump: It is used to detect, capture and analyze memory dump files when the system crashes, which is essential for diagnosing and solving critical errors. The kdump mechanism is based on kexec, which is an efficient kernel crash dump technology. When the system crashes, kexec can seamlessly restart a dedicated kdump kernel, whose main responsibility is to capture and dump the memory state at the time of the crash. This process involves collecting memory data before the kernel crashes and generating a memory dump file called vmcore, which is essentially a mirror of the system's physical memory. The vmcore file contains comprehensive and complete information when the system crashes, which is essential for analyzing and locating various complex and difficult problems. By deeply analyzing the vmcore file, system administrators and developers can diagnose the root cause of the kernel crash and take appropriate repair measures accordingly.

[0043] IPMI: Intelligent Platform Management Interface is implemented through a dedicated controller that can be part of the server processor or integrated into the baseboard management controller. IPMI is designed to be independent of the server's central processor, basic input and output system, or operating system. It runs inside the server as an independent, agentless management subsystem. By providing support for IPMI, BMC can still perform key management operations such as power on and off, information extraction, etc. when the operating system is unresponsive or not loaded. This capability greatly enhances the manageability and maintainability of the server, especially when problems occur at the operating system level. Through IPMI, administrators can use the command line interface to control the server to perform operations such as remote power on and off, monitor system health, collect system logs, and update firmware and software. IPMI also supports intervention during the system startup process, allowing administrators to perform specific management tasks before the operating system is loaded.

[0044] Ipmitool: A command line interface tool that allows system administrators to interact efficiently with BMC and execute various management instructions, including reading the sensor data repository (SDR) to obtain and print sensor values, displaying the contents of the system event log (SEL), printing the inventory information of the field replaceable unit (FRU), and reading and setting LAN configuration parameters. These functions make Ipmitool an important tool for remote server control and provide great convenience for daily operation and management of servers.

[0045] RedFish: An emerging server management standard that provides more modern and secure features than IPMI. RedFish supports a wider range of hardware platforms and uses JSON (JavaScript Object Notation, a lightweight data exchange format) and HTTPS (Hyper Text Transfer Protocol Secure, used to protect network data transmission security) to provide an easier-to-use interface and stronger security. Many existing BMCs support the use of IPMI and RedFish at the same time, allowing new and old technologies to coexist, ensuring compatibility and future scalability of management solutions.

[0046] The Linux (an operating system) kernel has excellent stability and fault tolerance, which enables the system to avoid catastrophic failures in most cases. However, due to various reasons, system crashes may still occur, although this is not common. BMC is a dedicated small operating system independent of the server's main operating system. It is integrated in a dedicated chip on the motherboard and provides comprehensive remote management and monitoring functions for the server. BMC can perform a series of interactive operations including remote server startup, shutdown, restart, hardware status monitoring, system installation and fault diagnosis. When a server restart event occurs, BMC not only records a detailed restart event log, but also has the ability to send real-time alarm notifications to administrators, thereby ensuring real-time control and rapid response to server status. This integrated hardware management solution significantly improves the maintainability and reliability of the server and is an indispensable part of modern data centers.

[0047] In server management practice, although users can learn about server restart events through BMC, it is difficult to distinguish whether the restart is due to normal system maintenance operations or abnormal restart due to system downtime. The reasons are as follows:

[0048] When the kdump process is executed and completed normally, the kdump kernel will successfully capture and generate a vmcore file and trigger an automatic restart. This restart operation is consistent with the manual restart instruction of the user in the operating system. Therefore, although the BMC can record the system restart event, it cannot clearly identify the specific reason for the restart in its notification event, whether it is a normal restart or an abnormal restart caused by a downtime triggering kdump. Furthermore, the user cannot immediately know whether the system has experienced a downtime problem in the BMC interface or alarm information. The user can only infer whether a downtime has occurred by checking whether the server has generated a vmcore file after the system restarts. Furthermore, even if the kdump process is triggered, it may fail for various reasons, resulting in the inability to generate a vmcore file normally. These reasons may include: insufficient memory space reserved for the second kernel, insufficient space in the configured dump path or file system, non-existence of the path, or other abnormal conditions. In this case, although kdump has been attempted to execute, because the vmcore file cannot be successfully saved, the system will automatically restart according to the default settings. After this restart, the user also cannot get any prompt from the BMC that the system may have crashed.

[0049] In order to solve the above problems, the present invention proposes a restart identification method, which is specifically referred to as Figure 1 , Figure 1 A flowchart of a restart identification method provided by an embodiment of the present invention. The method may include:

[0050] S101: The server restarts.

[0051] The executor of this embodiment is a server. The systems mentioned in this embodiment are all operating systems of the server, and the operating systems are all Linux operating systems. When the server restarts, at the moment of system interruption, whether it is a normal interruption or an abnormal interruption, the restart instruction will be automatically executed. This embodiment does not limit the method for determining whether the server is a normal restart. The following embodiment provides a determination example. If it is an abnormal system interruption, that is, a restart caused by a system crash, the kdump (kernel crash dump) mechanism will be triggered. Therefore, this embodiment can determine whether the server restart event is a normal restart based on whether the kdump mechanism is triggered.

[0052] S102: If the server is restarted normally, a normal restart flag is sent to the controller.

[0053] The controller in this embodiment refers to the BMC. For a normal restart event, this embodiment sends a normal restart mark to the BMC through a preset normal restart instruction, that is, the BMC knows that this restart event is a normal kernel restart event through the clear mark.

[0054] Further, in order for the controller to promptly learn the reason for the server restart, if the server restarts normally, a normal restart identifier is sent to the controller, which may include the following steps:

[0055] If the server restarts normally due to system maintenance operations, a normal restart instruction is executed, which includes a restart instruction and a normal restart flag sending instruction; the normal restart flag sending instruction sends the normal restart flag to the controller through a command line tool or an out-of-band management framework.

[0056] Specifically, when the server restarts, the reboot instruction (restart instruction) will be automatically executed, which is actually implemented through the systemdx (system and management server) service. Therefore, this embodiment can pre-configure the reboot instruction, that is, add a preset normal restart flag sending instruction to the configuration of the / usr / lib / systemd / system / systemd-reboot.service service that the system executes the reboot call, and the reconfigured reboot instruction is the normal restart instruction. When the server restarts, when the restart instruction is executed, the normal restart flag sending instruction will also be executed. The normal restart flag sending instruction can send the normal restart flag to the BMC through ipmitool (command line tool) or RedFish (out-of-band management framework).

[0057] S103: If the server is restarted abnormally, system operation data is captured in real time, and the system operation data and an abnormal restart identifier are sent to the controller; the system operation data at least includes register information and kernel stack information.

[0058] Specifically, if the system downtime or system crash triggers the kdump mechanism, the kdump process is executed, and the server restarts abnormally. Regardless of the execution result of the kdump process, the system will capture key system operation data in real time, which at least includes register information and kernel stack information, and send this information and the abnormal restart identifier to the BMC. The BMC can then know that the server restart event is an abnormal restart, and can also determine the exact timestamp of the system crash and detailed kernel stack trace information based on the information obtained.

[0059] Furthermore, in order to make BMC monitoring more comprehensive and refine the server functions, if the server is restarted abnormally, the system operation data is captured in real time, and the system operation data and the abnormal restart mark are sent to the controller, which may include the following steps:

[0060] When a server crashes, it will automatically trigger an abnormal restart of the kernel crash dump mechanism, and execute a pre-configured first script, which includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a system operation data sending instruction, and a restart instruction.

[0061] Specifically, when a server crashes, the kernel crash dump mechanism is automatically triggered. Therefore, a clear flag, namely the kdump mechanism trigger flag, is added to the restart service configuration to indicate that the kdump process has been triggered. The kdump mechanism trigger flag is sent to the BMC so that the BMC knows that the current server is in the kernel crash dump stage. It should be noted that the execution of the system operation data capture instruction takes precedence over the execution of the restart instruction.

[0062] Furthermore, in order to make the controller monitoring more comprehensive, the server function is further refined. If the server is restarted abnormally, the system operation data is captured in real time, and the system operation data and the abnormal restart mark are sent to the controller, which may include the following steps:

[0063] When a system crash occurs on the server, an abnormal restart of the kernel crash dump mechanism is automatically triggered, and a pre-configured second script is executed, the second script including a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a restart instruction, and a memory dump file identification instruction;

[0064] Among them, the memory dump file identification instruction includes: if the kernel crash dump mechanism is triggered normally, the memory dump file is successfully generated, and the kernel crash dump mechanism success identification sending instruction, the memory dump file sending instruction and the kernel restart identification sending instruction are triggered; if the kernel crash dump mechanism is triggered abnormally, the memory dump file generation fails, and the kernel crash dump mechanism failure identification sending instruction, the system operation data sending instruction and the kernel restart identification sending instruction are triggered.

[0065] The purpose of this step is to make corresponding identification according to the execution of the kdump process. It is necessary to configure the preset script executed in the kdump kernel in advance, that is, the second script. This script contains a series of preset instructions. The following is an explanation of the instructions related to the vmcore (memory dump) file:

[0066] (1) Memory transfer file identification instruction: This instruction is used to determine whether the vmcore file is saved successfully or not. By adding logical judgment, it is determined whether the vmcore file has been successfully generated and saved. In this embodiment, the successful generation of the vmcore file refers to the successful saving of the vmcore file; the failure to generate the vmcore file refers to the failure to save the vmcore file.

[0067] (2) The kernel crash dump mechanism successfully identifies the sending instruction: indicating that the vmcore file is successfully generated, that is, the vmcore file is successfully saved.

[0068] (3) If the kernel crash dump mechanism fails to send the instruction, it indicates that the vmcore file fails to be saved, and the corresponding error information needs to be recorded.

[0069] This embodiment can pre-configure various instructions, such as kernel crash dump mechanism trigger identification sending instructions, memory dump file identification instructions, kernel crash dump mechanism success identification sending instructions, kernel crash dump mechanism failure identification sending instructions and kernel restart identification sending instructions, so that the BMC can timely understand the various stages and restart processes experienced by the server, and can send the vmcore file to the BMC when it is successfully generated, because the vmcore file contains comprehensive and complete information when the system crashes, which is crucial for analyzing and locating various complex and difficult problems. The BMC can help system administrators and developers to timely diagnose the root cause of the kernel crash by deeply analyzing the vmcore file, and take corresponding repair measures accordingly; and when the vmcore file fails to be generated, the system operation data can be sent to the BMC, which can also play the same role as the vmcore file.

[0070] Furthermore, in order to transmit information quickly and efficiently, the above-mentioned triggering memory transfer file sending instruction may include the following steps:

[0071] Before executing the restart command, the memory dump file is obtained by calling the kdump_post parameter, and the register information and kernel stack information in the memory dump file are sent to the controller.

[0072] This step is based on the successful generation of the vmcore file. By using the kdump_post parameter in the kdump service configuration file / etc / kdump.conf, the sendtobmc.sh script is deployed and configured. This setting enables the script to be automatically triggered after the kdump service successfully captures the vmcore file. The sendtobmc.sh script extracts register information and kernel stack information from the vmcore-dmesg.txt file and sends it to the BMC.

[0073] Furthermore, after the memory dump file is successfully generated, the following steps may be included:

[0074] Stop capturing system operation data, and set the priority of sending the memory dump file instruction to be higher than the priority of sending the system operation data to the controller, so that the controller can display the register information and kernel stack information in the memory dump file in real time.

[0075] The purpose of this step is to stop the action of capturing system operation data when the memory dump file is successfully generated. This can save some server resources so that the server can perform other actions. Subsequently, only the register information and kernel stack information in the vmcore file need to be sent to the BMC. The BMC displays information to inform the user of the restart reason of the current system restart event, helping the BMC analyze the cause of the system crash.

[0076] Furthermore, in order to transmit information quickly and efficiently, the trigger system executes the data sending instruction, which may include the following steps:

[0077] Before executing the restart instruction, system operation data is extracted from the dmesg log and sent to the controller.

[0078] This step is based on the failure of vmcore file generation. You need to modify the / usr / lib / systemd / system / systemd-reboot.service service in the kdump kernel. Before the system restarts, get the system operation data from the dmesg (kernel log query) log and send it to the BMC. This will help the BMC analyze the cause of the system crash.

[0079] Furthermore, in order for the user to timely understand the server restart status and make corresponding strategies, the above-mentioned sending of the system operation data and the abnormal restart identifier to the controller may include the following steps:

[0080] System operation data and abnormal restart flags are sent to the controller through the command line tool or out-of-band management framework, displayed on the controller, and recorded one by one in the event log of the server.

[0081] Specifically, when the system crashes, critical system operation data will be captured in real time. The captured system operation data will be encapsulated into a structured format and securely transmitted to the BMC with preset instructions, and the data will be recorded in an unalterable event log.

[0082] Furthermore, BMC can notify users in the following two ways: (1) Passive acquisition by users: The system log interface on the BMC side displays the received kernel stack information and register information in real time, and can define the alarm level and send alarm information to users through configuration; or the system operation data is presented in real time on the user interface, so that users can intuitively identify the occurrence time, triggering cause and related system status of the downtime event, and improve the speed and accuracy of fault diagnosis through intuitive information display. (2) Active acquisition by users: Users can actively access the BMC interface to query the detailed information of the restart event. In the BMC interface, users can view the reasons for the system restart, including whether it is caused by system downtime, as well as the relevant event details and occurrence time. In addition, the kernel stack information and register information displayed on the BMC interface provide users with valuable data, which can be used to preliminarily analyze the cause of the problem that may cause the system downtime. With this detailed technical information, system administrators can quickly locate the problem and formulate corresponding solutions and preventive measures.

[0083] The restart identification method provided by the embodiment of the present invention is applied. When the server is restarted, it is determined whether the server is restarted normally; if the server is restarted normally, the normal restart identification is sent to the controller; if the server is restarted abnormally, the system operation data is captured in real time, and the system operation data and the abnormal restart identification are sent to the controller; the system operation data at least includes register information and kernel stack information. The beneficial effect of this method is that by strengthening the server system function, the server can send the corresponding restart identification to the controller according to the restart situation, the controller's monitoring ability of the server is enhanced, so that it can monitor the health status of the server in real time, and the system administrator can directly know the reason for the restart of the server, so as to further analyze the health status of the server according to the restart reason, and make corresponding decisions in time when abnormal. This provides a valuable time window for the system administrator to respond quickly and take measures. In addition, by utilizing IPMI and RedFish technology, the system is provided with the ability to communicate with BMC, and the identification and notification mechanism of the system restart event is realized. The notification mechanism can accurately convey the cause and nature of the restart through BMC when a restart event occurs in the system, whether it is a normal system restart or a restart after the kdump process triggered by system downtime. Moreover, by combining active and passive information acquisition methods, users not only improve the visibility of system failures, but also enhance the timeliness of problem handling, making system management more efficient and accurate.

[0084] In order to make the present invention easier to understand, please refer to Figure 2 , Figure 2 The flowchart of the restart identification method provided by the embodiment of the present invention may specifically include:

[0085] For a normal restart event of the system, a notification event is sent to the BMC through a preset restart instruction. The notification event is used to notify the BMC through a normal restart identifier that the restart reason of this system restart event is a normal restart and no downtime.

[0086] For the system restart event that triggers the kdump mechanism when the system is down, the server distinguishes whether the kdump process is executed successfully or failed. Regardless of the execution result of the kdump process, the server will capture the key panic stack (kernel stack information) in real time and send the kernel crash dump mechanism trigger mark. Further, according to the execution result of the kdump process, the corresponding vmcore file saving success mark or saving failure mark is executed. Regardless of whether the vmcore file is generated or not, it will automatically restart and send a notification event to the BMC according to the preset restart instruction. The notification event is used to notify the BMC that this system restart event is a kernel restart through the kernel restart mark. Further, if the vmcore file is generated successfully, the BMC determines that the system is down through the kernel crash dump mechanism success mark and triggers the kdump to restart successfully; if the vmcore file is generated unsuccessfully, the BMC determines that the system is down through the kernel crash dump mechanism failure mark and triggers the kdump to restart after failure; after receiving the kernel stack information, the BMC will record them in the system event log and display them in the BMC user interface log system, so that users can timely understand the specific time of the system downtime event and the cause of the downtime.

[0087] The following is an introduction to a restart identification device provided by an embodiment of the present invention. The restart identification device described below and the restart identification method described above can be referred to each other.

[0088] Please refer to Figure 3 , Figure 3 A schematic diagram of a restart identification device provided in an embodiment of the present invention may include:

[0089] The restart mode determination module 100 is used to determine whether the server is restarted normally when the server is restarted;

[0090] A normal restart module 200, configured to send a normal restart identifier to a controller if the server is restarted normally;

[0091] The abnormal restart module 300 is used to capture system operation data in real time if the server is abnormally restarted, and send the system operation data and the abnormal restart identifier to the controller; the system operation data at least includes register information and kernel stack information.

[0092] Based on the above embodiment, the normal restart module 200 may include:

[0093] A normal restart unit is used to execute a normal restart instruction if the server is restarted normally due to a system maintenance operation. The normal restart instruction includes a restart instruction and a normal restart flag sending instruction; the normal restart flag sending instruction sends the normal restart flag to the controller through a command line tool or an out-of-band management framework.

[0094] Based on the above embodiment, the abnormal restart module 300 may include:

[0095] The first abnormal restart unit is used to automatically trigger an abnormal restart of the kernel crash dump mechanism when the server has a system crash, and then execute a pre-configured first script, wherein the first script includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a system operation data sending instruction and a restart instruction.

[0096] Based on the above embodiment, the abnormal restart module 300 may include:

[0097] A second abnormal restart unit, used for automatically triggering an abnormal restart of a kernel crash dump mechanism when a system crash occurs on the server, and executing a pre-configured second script, wherein the second script includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a restart instruction, and a memory dump file identification instruction;

[0098] The memory transfer file identification instruction includes:

[0099] If the kernel crash dump mechanism is triggered normally, a memory dump file is successfully generated, and a kernel crash dump mechanism success mark sending instruction, a memory dump file sending instruction, and a kernel restart mark sending instruction are triggered;

[0100] If the kernel crash dump mechanism is not triggered normally, the memory dump file generation fails, and a kernel crash dump mechanism failure identification sending instruction, a system operation data sending instruction, and a kernel restart identification sending instruction are triggered.

[0101] Based on the above embodiment, the second abnormal restart unit may include:

[0102] The first acquisition unit is used to acquire the memory dump file by calling the kdump_post parameter before executing the restart instruction, and send the register information and the kernel stack information in the memory dump file to the controller.

[0103] Based on the above embodiment, the second abnormal restart unit may include:

[0104] The second acquisition unit is used to extract the system operation data from the dmesg log before executing the restart instruction, and send it to the controller.

[0105] Based on the above embodiment, the abnormal restart module 300 may include:

[0106] A sending unit is used to send the system operation data and abnormal restart identification to the controller through a command line tool or an out-of-band management framework, display them on the controller, and record them one by one in the event log of the server.

[0107] It should be noted that the order of the modules and units in the above restart identification device can be changed without affecting the logic.

[0108] The restart identification device provided by the embodiment of the present invention is applied, through the restart mode determination module 100, used to determine whether the server is restarted normally when the server is restarted; the normal restart module 200 is used to send the normal restart identification to the controller if the server is restarted normally; the abnormal restart module 300 is used to capture the system operation data in real time if the server is restarted abnormally, and send the system operation data and the abnormal restart identification to the controller; the system operation data at least includes register information and kernel stack information. The beneficial effect of this device is that: by strengthening the server system function, the server can send the corresponding restart identification to the controller according to the restart situation, the controller's monitoring ability of the server is enhanced, so that it can monitor the health status of the server in real time, and the system administrator can directly know the reason for the server restart, so as to further analyze the health status of the server according to the restart reason, and make corresponding decisions in time when abnormal. This provides a valuable time window for system administrators to respond quickly and take measures.

[0109] In addition, by using IPMI and RedFish technology, the system is provided with the ability to communicate with the BMC, and a system restart event identification and notification mechanism is implemented. This notification mechanism can accurately convey the cause and nature of the restart through the BMC when a system restart event occurs, whether it is a normal system restart or a restart after the kdump process triggered by a system crash. In addition, users can obtain information through a combination of active and passive methods, which not only improves the visibility of system failures, but also strengthens the timeliness of problem handling, making system management more efficient and accurate.

[0110] Figure 4 A schematic diagram of a restart identification device provided by an embodiment of the present invention is shown in FIG. Figure 4 As shown, restarting the identification device includes:

[0111] A memory 60, for storing computer programs;

[0112] The processor 61 is used to implement the steps of the restart identification method in the above embodiment when executing the computer program.

[0113] The restart identification device provided in this embodiment may include but is not limited to a smart phone, a tablet computer, a laptop computer, or a desktop computer.

[0114] Among them, the processor 61 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 61 can be implemented in at least one hardware form of digital signal processing (DSP), field-programmable gate array (FPGA), and programmable logic array (PLA). The processor 61 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a central processing unit (CPU); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 61 may be integrated with a graphics processing unit (GPU), and the GPU is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 61 may also include an artificial intelligence (AI) processor, which is used to process computing operations related to machine learning.

[0115] The memory 60 may include one or more computer-readable storage media, which may be non-transitory. The memory 60 may also include a high-speed random access memory, and a non-volatile memory, such as one or more disk storage devices, flash memory storage devices. In this embodiment, the memory 60 is at least used to store the following computer program 601, wherein, after the computer program is loaded and executed by the processor 61, it can implement the relevant steps of the restart identification method disclosed in any of the aforementioned embodiments. In addition, the resources stored in the memory 60 may also include an operating system 602 and data 603, etc., and the storage method may be temporary storage or permanent storage. Among them, the operating system 602 may include Windows, Unix, Linux, etc. Data 603 may include, but is not limited to, data of the restart identification method, etc.

[0116] In some embodiments, the restart identification device may further include a display screen 62 , an input / output interface 63 , a communication interface 64 , a power supply 65 , and a communication bus 66 .

[0117] Those skilled in the art will understand that Figure 4 The structure shown in the figure does not constitute a limitation on the restart identification device, and may include more or fewer components than those shown in the figure.

[0118] It is understandable that if the restart identification method in the above embodiment is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention is essentially or part of the contribution to the current technology or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium to execute all or part of the steps of the methods of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM), random access memory (RAM), electrically erasable programmable ROM, register, hard disk, removable disk, CD-ROM, magnetic disk or optical disk and other media that can store program code.

[0119] Based on this, an embodiment of the present invention further provides a computer-readable storage medium, on which a computer program is stored. When the computer program is executed by a processor, the steps of the restart identification method described above are implemented.

[0120] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0121] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in the above description according to function. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of the present invention.

[0122] Finally, it should be noted that, in this article, relationships such as first and second, etc. are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprises" or any other variations are intended to cover non-exclusive inclusion, so that a process, method, article or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device.

[0123] The above is a detailed introduction to a restart identification method, device, equipment and computer-readable storage medium provided by the present invention. Specific examples are used in this article to illustrate the principles and implementation methods of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea; at the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation method and application scope. In summary, the content of this specification should not be understood as a limitation on the present invention.

Claims

1. A restart identification method, characterized in that: include: When the server is restarted, determining whether the server is restarted normally; If the server is restarted normally, a normal restart identifier is sent to the controller; If the server is restarted abnormally, capturing system operation data in real time, and sending the system operation data and an abnormal restart identifier to the controller; The system operation data at least includes register information and kernel stack information.

2. The restart identification method according to claim 1, characterized in that: If the server is restarted normally, a normal restart flag is sent to the controller, including: If the server restarts normally due to a system maintenance operation, a normal restart instruction is executed, and the normal restart instruction includes a restart instruction and a normal restart flag sending instruction; the normal restart flag sending instruction sends the normal restart flag to the controller through a command line tool or an out-of-band management framework.

3. The restart identification method according to claim 1, characterized in that: If the server is restarted abnormally, capturing system operation data in real time, and sending the system operation data and an abnormal restart identifier to the controller, including: When the server experiences a system crash, it will automatically trigger an abnormal restart of the kernel crash dump mechanism, and execute a pre-configured first script, which includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a system operation data sending instruction and a restart instruction.

4. The restart identification method according to claim 1, characterized in that: If the server is restarted abnormally, capturing system operation data in real time, and sending the system operation data and an abnormal restart identifier to the controller, including: When the server experiences a system crash, an abnormal restart of the kernel crash dump mechanism is automatically triggered, and a pre-configured second script is executed, wherein the second script includes a kernel crash dump mechanism trigger identification sending instruction, a system operation data capture instruction, a restart instruction, and a memory dump file identification instruction; The memory transfer file identification instruction includes: If the kernel crash dump mechanism is triggered normally, a memory dump file is successfully generated, and a kernel crash dump mechanism success mark sending instruction, a memory dump file sending instruction, and a kernel restart mark sending instruction are triggered; If the kernel crash dump mechanism is not triggered normally, the memory dump file generation fails, and a kernel crash dump mechanism failure identification sending instruction, a system operation data sending instruction, and a kernel restart identification sending instruction are triggered.

5. The restart identification method according to claim 4, characterized in that: Triggering the memory transfer file sending instruction includes: Before executing the restart instruction, the memory dump file is acquired by calling the kdump_post parameter, and the register information and the kernel stack information in the memory dump file are sent to the controller.

6. The restart identification method according to claim 4, characterized in that: Triggering the system to run a data sending instruction includes: Before executing the restart instruction, the system operation data is extracted from the dmesg log and sent to the controller.

7. The restart identification method according to claim 1, characterized in that: Sending the system operation data and the abnormal restart mark to the controller includes: The system operation data and the abnormal restart identifier are sent to the controller through a command line tool or an out-of-band management framework, displayed on the controller, and recorded item by item in the event log of the server.

8. A restart identification device, characterized in that: include: A restart mode determination module, used to determine whether the server is restarted normally when the server is restarted; A normal restart module, configured to send a normal restart identifier to the controller if the server is restarted normally; An abnormal restart module, used for capturing system operation data in real time if the server is abnormally restarted, and sending the system operation data and an abnormal restart identifier to the controller; The system operation data at least includes register information and kernel stack information.

9. A restart identification device, characterized in that: include: Memory for storing computer programs; A processor, configured to implement the steps of the restart identification method according to any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps of the restart identification method according to any one of claims 1 to 7 are implemented.

Images