Downtime processing method and electronic device

Abstract

The application discloses a downtime processing method and electronic equipment, and relates to the technical field of computers.The application can learn the current situation of a test terminal device in time by monitoring the state of the test terminal device, such as at least one of user interaction behavior, a power supply state and a kernel state, thereby determining whether the test terminal device has downtime according to the monitored state data, and further determining whether the downtime is real or false, and then performing downtime processing according to the power-off protection mode of a solid state disk in the case of real downtime, and performing downtime processing according to a user space checkpoint / recovery tool in the case of false downtime, so that automatic downtime processing is realized, and the efficiency of downtime processing is improved compared with the manual downtime processing mode in the prior art, thereby improving the overall test efficiency.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer, and particularly relates to a down processing method and an electronic device. BACKGROUND

[0002] In an automatic test scene, a test terminal device needs to guarantee test continuity, but in a test process, the test terminal device can appear a down phenomenon, which needs an operation and maintenance personnel to manually process the down, but the efficiency of manual down processing is low, which affects the overall test efficiency. SUMMARY

[0003] The present application provides a down processing method and an electronic device, which at least solve the problem of low efficiency of manual down processing in the related art, which affects the overall test efficiency.

[0004] The present application provides a down processing method, comprising:

[0005] monitoring a state of a test terminal device; the state comprises a user interaction behavior, and the user interaction behavior comprises an input event of a physical input device; the state further comprises at least one of a power state and a kernel state;

[0006] determining whether the test terminal device has a down according to monitored state data, and determining a down type; the down type is a real down or a false down; the state data comprises input event related data; the false down is determined according to the input event related data; the state data further comprises at least one of power state related data and kernel state related data; the real down is determined according to at least one of the power state related data and the kernel state related data;

[0007] in a case where the test terminal device has a down, performing down processing according to a preset processing strategy corresponding to the down type; the preset processing strategy corresponding to the real down comprises a power-off protection mode of a solid state disk; and the preset processing strategy corresponding to the false down comprises a user space checkpoint / recovery tool.

[0008] The present application further provides a down processing device, comprising:

[0009] a monitoring module, configured to monitor a state of a test terminal device; the state comprises a user interaction behavior, and the user interaction behavior comprises an input event of a physical input device; the state further comprises at least one of a power state and a kernel state;

[0010] The determining module is configured to determine whether a crash of the test-side device occurs according to the monitored state data, and determine a crash type; the crash type is a true crash or a false crash; the state data includes input event related data; the false crash is determined according to the input event related data; the state data further includes at least one of power state related data and kernel state related data; the true crash is determined according to at least one of the power state related data and the kernel state related data;

[0011] The processing module is configured to, in the case that the test-side device crashes, perform crash processing according to a preset processing strategy corresponding to the crash type; the preset processing strategy corresponding to the true crash includes a power-off protection mode of a solid state disk; and the preset processing strategy corresponding to the false crash includes a user space checkpoint / resume tool.

[0012] The application further provides an electronic device, including a memory configured to store a computer program, and a processor configured to execute the computer program to implement the steps of any of the crash processing methods.

[0013] The application further provides a computer readable storage medium, which stores a computer program, and the computer program is executed by a processor to implement the steps of any of the crash processing methods.

[0014] The application further provides a computer program product, which includes a computer program, and the computer program is executed by a processor to implement the steps of any of the crash processing methods.

[0015] The crash processing method and the electronic device provided by the application can know the current situation of the test-side device in time by monitoring the state of the test-side device, for example, at least one of user interaction behavior, power state and kernel state, so as to determine whether a crash of the test-side device occurs according to the monitored state data, and further determine whether it is a true crash or a false crash, and then perform crash processing according to the power-off protection mode of a solid state disk in the case of a true crash, and perform crash processing according to a user space checkpoint / resume tool in the case of a false crash, so as to realize automatic crash processing, and the efficiency of crash processing is improved compared with the manual crash processing in the related art, so as to improve the overall test efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the embodiments of the application, the drawings needed in the embodiments will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative labor.

[0017] Figure 1A schematic diagram of a system architecture provided for the present application;

[0018] Figure 2 A flowchart of a downtime processing method provided for the present application;

[0019] Figure 3 A flowchart of another downtime processing method provided for the present application;

[0020] Figure 4 A structural schematic diagram of a downtime processing apparatus provided for the present application;

[0021] Figure 5 A structural schematic diagram of an electronic device provided for the present application. DETAILED DESCRIPTION

[0022] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, other embodiments obtained by those skilled in the art without creative work fall within the protection scope of the present application.

[0023] It should be noted that, in the description of the present application, the terms "comprise", "contain" or any other variant thereof are intended to cover non-exclusive inclusion, so that the process, method, article or device comprising a series of elements not only includes those elements, but also includes other elements not explicitly listed or inherent to such process, method, article or device. The terms "first", "second" and the like in the present application are used to distinguish similar objects, and are not used to describe a specific order or sequence.

[0024] Linux: an operating system.

[0025] Downtime refers to the state of a computer, server or system stopping responding, crashing or freezing.

[0026] In an automated test scenario, the test end device needs to ensure test continuity, but during the test process, the test end device may appear downtime phenomenon. In this case, the operation and maintenance personnel need to manually process the downtime, but the efficiency of manual downtime processing is low, which affects the overall test efficiency.

[0027] In view of the above technical problems, considering that the downtime may be a true downtime or a false downtime, the true downtime refers to that the test-side device completely stops working and cannot be operated or recovered through any way. This situation is usually caused by a serious hardware failure or system crash. The false downtime refers to that the operating system of the test-side device is unresponsive but the kernel is alive. Different types of downtime require different processing methods, so when the test-side device has a downtime, the type of the downtime of the test-side device can be determined first, and then the downtime processing is performed.

[0028] Specifically, by monitoring the state of the test-side device, for example, at least one of the user interaction behavior, the power state and the kernel state, the current situation of the test-side device can be learned in a timely manner, so that whether the test-side device has a downtime is determined according to the monitored state data, and whether it is a true downtime or a false downtime can be further determined, and then in the case of a true downtime, the downtime processing is performed according to the power-off protection mode of the solid state disk, and in the case of a false downtime, the downtime processing is performed according to the user space checkpoint / recovery tool, thereby realizing the automatic downtime processing. Compared with the manual downtime processing method in the related art, the efficiency of the downtime processing is improved, thereby improving the overall test efficiency.

[0029] In order for those skilled in the art to better understand the present application, the present application will be further described in detail below in combination with the drawings and specific embodiments.

[0030] In combination with the specific application environment architecture or the specific hardware architecture on which the downtime processing method is dependent, the specific application environment architecture or the specific hardware architecture is described here.

[0031] Figure 1 A schematic diagram of a system architecture provided by the present application is shown in Figure 1 The test-side device 10 and the monitoring-side device 20 are in communication connection.

[0032] The test-side device 10 is used for automatic testing. Illustratively, the test-side device 10 is equipped with automatic testing software, which is used to execute a preset test case and collect performance data and logs during testing. After the test is completed, the test-side device 10 generates a test report and stores it.

[0033] Illustratively, the test-side device 10 is a server or a terminal device. For example, the terminal device is a notebook computer, a desktop computer or other devices that can be automatically tested.

[0034] The monitoring-side device 20 receives the remote desktop stream and test data transmitted by the test-side device 10 in real time, and synchronously displays the test execution screen and key indicators (such as progress, error prompts) through a graphical interface. The user can actively send control instructions (such as pausing or terminating the test) to the test-side device 10 through the monitoring-side device 20.

[0035] Exemplarily, the monitoring terminal device 20 is a terminal device. For example, the terminal device is a notebook computer, a desktop computer, or other remotely controllable devices.

[0036] Optionally, the test terminal device 10 and the monitoring terminal device 20 interact with each other through a remote desktop protocol. For example, the graphical desktop sharing is performed through Virtual Network Computing (VNC).

[0037] The monitoring terminal device 20 is in communication connection with a physical input device. The physical input device is a device connected to the user terminal through a Universal Serial Bus (USB), which is referred to as a USB device, such as a mouse, a keyboard, and the like.

[0038] In one scenario, a user inputs a control instruction by operating the physical input device. The user's operation of the physical input device can be regarded as a user interaction behavior, and the user interaction behavior triggers an input event of the physical input device.

[0039] In another scenario, an automatic program is pre-set on the monitoring terminal device 20, and the automatic program is used to periodically trigger the input event. The user interaction behavior is simulated through the automatic program, so that the user does not need to be on duty in front of the monitoring terminal device 20 at all times, and the labor cost is saved.

[0040] The monitoring terminal device 20 sends the detected input event to the test terminal device 10 in real time, so that the test terminal device 10 performs the crash handling method provided in the present application.

[0041] The present application is applicable to long-period stress testing which needs to ensure test continuity.

[0042] The execution subject of the crash handling method provided in the present application is a crash handling device, which is integrated in an electronic device. Exemplarily, the electronic device is the test terminal device 10.

[0043] Figure 2 A flowchart of a crash handling method provided in the present application is shown in FIG. 1. As shown in FIG. 1, the method comprises the following steps. Figure 2

[0044] S201: Monitor the state of the test terminal device.

[0045] The state of the test terminal device includes a user interaction behavior.

[0046] ​The user interaction behavior refers to a behavior of a user operating a physical input device on a monitoring terminal device side, which triggers an input event of the physical input device. For the test terminal device, monitoring the user interaction behavior means monitoring the input event of the physical input device. Therefore, the user interaction behavior can be considered to include the input event of the physical input device.

[0047] The state of the test terminal device further includes at least one of a power state and a kernel state.

[0048] The power state is used to indicate whether the power of the test terminal device is abnormal.

[0049] The kernel state is used to indicate whether the network state of the kernel of the test terminal device is abnormal.

[0050] Optionally, the user interaction behavior, the power state and the kernel state of the test terminal device are monitored respectively. For example, the user interaction behavior of the test terminal device is monitored to obtain input event related data; the power state of the test terminal device is monitored to obtain power state related data; and the kernel state of the test terminal device is monitored to obtain kernel state related data.

[0051] S202: Determine whether the test terminal device has a crash according to the monitored state data, and determine a crash type.

[0052] The crash type is a true crash or a false crash.

[0053] The true crash means that the test terminal device completely stops working and cannot be operated or recovered by any means. This situation is usually caused by a serious hardware failure or system crash.

[0054] The false crash means that the operating system of the test terminal device is unresponsive but the kernel is alive.

[0055] In the case where the state of the test terminal device includes the user interaction behavior, the monitored state data is input event related data, and the input event related data includes a loss duration of a mouse event and a switching delay of a keyboard NumLock key.

[0056] The loss duration is a time difference between a current time and a last time of triggering the mouse event. The switching delay is a response time of the NumLock key. Accordingly, the false crash is determined according to the loss duration and the switching delay, that is, whether the test terminal device is in the false crash can be determined according to the loss duration of the mouse event and the switching delay of the keyboard NumLock key.

[0057] In a case where the state of the test-side device includes a power state, the monitored state data includes power state related data. The power state related data is used to indicate power normal or power abnormal. Power normal means that the power of the test-side device is in a normal working state. Power abnormal means that the power supply of the test-side device has a problem, such as power failure, unstable voltage, or power connection disconnection, etc. Accordingly, whether the test-side device is truly down can be determined according to the power state related data.

[0058] In a case where the state of the test-side device includes a kernel state, the monitored state data includes kernel state related data. The kernel state related data is used to indicate kernel network normal or kernel network abnormal. Kernel network normal means that the network of the kernel of the test-side device is normally connected. Kernel network abnormal means that the network of the kernel of the test-side device has a problem, such as network connection interruption. Accordingly, whether the test-side device is truly down can be determined according to the kernel state related data.

[0059] The true down is determined according to at least one of the power state related data and the kernel state related data.

[0060] Exemplarily, a decision engine is pre-deployed in the test-side device, and step S202 is implemented through the decision engine. For example, the decision engine can be implemented through a rule tree.

[0061] Optionally, when it is determined that the test-side device has a false down, a false down signal is output; or when it is determined that the test-side device has a true down, a true down signal is output. So that the test-side device performs step S203 in response to the true down signal or the false down signal.

[0062] S203: In a case where the test-side device has a down, a preset processing strategy corresponding to the down type is used for down processing.

[0063] The application sets corresponding preset processing strategies for the two cases of true down and false down: the preset processing strategy corresponding to the true down includes a power loss protection (PLP) mode of a solid state drive (SSD); and the preset processing strategy corresponding to the false down includes a checkpoint / restore in userspace (CRIU) tool.

[0064] Through the above preset processing strategies, the down processing can be automatically performed.

[0065] Exemplarily, in response to the true down signal, the down processing is performed according to the preset processing strategy corresponding to the true down; or in response to the false down signal, the down processing is performed according to the preset processing strategy corresponding to the false down.

[0066] The present application can learn the current situation of the test terminal device in time by monitoring the state of the test terminal device, such as at least one of user interaction behavior, power state and kernel state, so as to determine whether the test terminal device crashes according to the monitored state data, and further determine whether it is a true crash or a false crash, and then perform crash processing according to the power-off protection mode of the SSD in the case of a true crash, and perform crash processing according to the user space checkpoint / recovery tool in the case of a false crash, thereby realizing automatic crash processing. Compared with the manual crash processing mode in the related art, the present application improves the efficiency of crash processing, thereby improving the overall test efficiency.

[0067] The determination and processing process of the false crash will be described below.

[0068] In some embodiments, the input event includes a mouse event and a toggle event of a keyboard number lock key. For example, the mouse event can be a mouse movement event or a mouse click event. Accordingly, in the case that the state of the test terminal device includes user interaction behavior, the monitoring of the state of the test terminal device in S201 is specifically implemented as steps (1)-(2).

[0069] (1): In response to the triggering of the mouse event, the number of occurrences of the mouse event and the triggering time of the mouse event are recorded, and in response to the pressing of the keyboard number lock key, the toggle delay of the keyboard number lock key is recorded, the toggle delay being the time difference between the pressing of the key and the change of the state indicator light.

[0070] The toggle delay can be regarded as the response time of the number lock key.

[0071] (2): The triggering time of the last recorded mouse event and the toggle delay are periodically detected according to a preset sampling rate, and the loss duration of the mouse event is calculated.

[0072] Optionally, the triggering time of the last recorded mouse event is periodically detected according to a preset sampling rate, and each time the detection is performed, the time difference between the current time and the triggering time is calculated, which can be regarded as the loss duration of the mouse event. It is determined whether the loss duration is greater than a preset time threshold. If the loss duration is greater than the preset time threshold, it means that the number of occurrences of the mouse event has not been updated for a long time, i.e., the mouse has not responded for a long time, and it can be considered that the mouse event is lost. If the loss duration is less than or equal to the preset time threshold, it means that the mouse event is not lost.

[0073] Optionally, the switching delay of the last recorded digital lock key is periodically detected according to a sampling rate, and at each detection, it is determined whether the switching delay is less than a preset delay threshold. If the switching delay is less than the preset delay threshold, it indicates that the keyboard response is normal; otherwise, if the switching delay is greater than or equal to the preset delay threshold, it indicates that the keyboard is stuck.

[0074] The sampling rate, the preset time threshold and the preset delay threshold can be set according to actual needs, for example, the sampling rate is 100 Hertz (Hz), the preset time threshold is 5 seconds (s), and the preset delay threshold is 200 milliseconds (ms), which are not limited by the present application.

[0075] For example, when the user moves the mouse or presses the keyboard on the monitoring terminal device, or when the automatic program in the monitoring terminal device triggers the input event, the monitoring terminal device captures the input event, and accordingly, the monitoring terminal device encapsulates the event type (such as mouse movement, mouse key, keyboard key, etc.) of the input event and the specific parameters (such as mouse coordinates, key code of the key, etc.) of the input event into a data packet in a specific format, and sends the data packet to the test terminal device.

[0076] Regarding the capture of the input event, the specific process includes: collecting the current signal from the keyboard and the mouse through the USB hub (Hub) and the current sensor; converting the analog current signal into a digital signal through an analog-to-digital converter (Analog-to-Digital Converter, ADC). For example, the rising edge delay of the mouse displacement and the keyboard digital lock key is captured. Wherein, the displacement can be expressed in the form of coordinates.

[0077] Correspondingly, when the test terminal device receives the data packet, it parses the data packet and performs corresponding operations. The corresponding operations include: determining the device that triggers the input event according to the event type; if the device that triggers the input event is a mouse, then the global counter is incremented by 1 to determine the number of mouse events, and the current time is recorded, which can be regarded as the trigger time of the mouse event. If the device that triggers the input event is a keyboard, and the pressed key is a digital lock key, then the time stamp of the key press is obtained, and the time stamp of the change of the status indicator light is recorded; calculate the time difference between the two time stamps, the unit is nanosecond, which can be regarded as the switching delay.

[0078] For example, the above-mentioned corresponding operations are performed by a field programmable gate array (Field-Programmable Gate Array, FPGA).

[0079] On the basis of steps (1)-(2), the determination of whether the test terminal device crashes and the determination of the crash type in S202 according to the monitored state data are specifically implemented as follows: in the case that the loss duration of the mouse event is greater than the preset time threshold and the switching time delay of the numeric lock key is less than the preset time delay threshold, it is determined that the test terminal device crashes, and the crash type is determined to be a false crash.

[0080] If the loss duration of the mouse event is greater than the preset time threshold and the switching time delay of the numeric lock key is less than the preset time delay threshold, it indicates that the mouse is unresponsive for a long time but the keyboard responds quickly, and this situation can determine that the test terminal device has a false crash.

[0081] The loss duration of the mouse event directly reflects the response capability of the graphical user interface (GUI), and if the GUI is stuck, the mouse event cannot be processed, resulting in a continuously increasing loss duration. The pressing of the keyboard numeric lock key triggers two actions: one is to send a key event to the operating system (software level), and the other is to cause a physical change of the status indicator light (hardware level, but controlled by the operating system). In a healthy system, the two actions are almost instantaneous and synchronous, and the time delay is extremely short. If the system is busy or stuck, the software processing slows down, but the control signal of the indicator light can still be sent out through the underlying driver, resulting in an abnormally increased switching time delay. By monitoring these two indicators at the same time, an accurate judgment can be made: a long loss duration indicates that the GUI is unresponsive, and a short switching time delay indicates that the underlying input driver and kernel interrupt processing can still be normal (otherwise the status indicator light will not light up), thereby excluding the possibility of a true crash. The combination of the two can accurately determine that the test terminal device has a false crash.

[0082] In addition, monitoring the switching time delay of the mouse event and the single key occupies less system resources, and based on continuous event monitoring and periodic time difference calculation, the unresponsive state can be quickly found, which is conducive to quickly triggering the preset processing strategy and reducing the crash time.

[0083] On the basis of the above embodiment, the kernel alive state can be combined to further determine whether a false crash occurs. Alternatively, the determination of whether the test terminal device crashes and the determination of the crash type in S202 according to the monitored state data are specifically implemented as follows: in the case that the loss duration is greater than the preset time threshold and the switching time delay is less than the preset time delay threshold, a process state checking command is sent to the kernel; in the case that the process state checking command can be executed and returns a result, the kernel alive state is determined to be kernel alive; and if the kernel alive state is determined to be kernel alive, it is determined that the test terminal device crashes, and the crash type is determined to be a false crash.

[0084] Exemplarily, the process state viewing command is a ps command. The ps command is a command used for displaying the current process state in a Linux system.

[0085] If the process state viewing command can be executed normally and returns a result, it indicates that the kernel can manage the process normally, and it can be considered that the kernel is in a normal working state, that is, it can be considered that the kernel is alive. If the kernel is alive, but the mouse is unresponsive for a long time but the keyboard is responsive quickly, it can be determined that the test terminal device has a false downtime.

[0086] By combining the kernel alive state to form a double judgment mechanism, the possibility of misjudgment is reduced.

[0087] If the loss duration of the mouse event is less than or equal to the preset time threshold, and the switching delay of the digital lock key is less than the preset delay threshold, it indicates that the mouse and keyboard responses are both normal, and no processing is performed.

[0088] If the loss duration of the mouse event is less than or equal to the preset time threshold, and the switching delay of the digital lock key is greater than or equal to the preset delay threshold, it indicates that the mouse response is normal, but the keyboard is stuck, and in this case, it can be determined that the test terminal device has a false downtime. Alternatively, the kernel alive state can be combined to further determine whether a false downtime occurs. Exemplarily, a process state viewing command is sent to the kernel; in the case that the process state viewing command can be executed and returns a result, it is determined that the kernel alive state is kernel alive; if it is determined that the kernel alive state is kernel alive, it is determined that the test terminal device has a downtime, and the downtime type is determined to be a false downtime.

[0089] If the loss duration of the mouse event is greater than the preset time threshold, and the switching delay of the digital lock key is greater than or equal to the preset delay threshold, it indicates that the mouse is unresponsive for a long time and the keyboard is stuck, and in this case, the kernel alive state can be combined to further determine whether a false downtime occurs. Exemplarily, a process state viewing command is sent to the kernel; in the case that the process state viewing command can be executed and returns a result, it is determined that the kernel alive state is kernel alive; if it is determined that the kernel alive state is kernel alive, it is determined that the test terminal device has a downtime, and the downtime type is determined to be a false downtime.

[0090] For the above case of determining whether a false downtime occurs in combination with the kernel alive state, if the process state viewing command is unresponsive, it indicates that the kernel may be in a deadlock, an infinite loop or other abnormal state, causing the kernel to be unable to process user space requests. This case does not belong to a false downtime, nor does it belong to a true downtime, and further judgment is required, for example, a prompt message can be sent to the monitoring terminal device to prompt the user that the kernel is abnormal, so that the user can promptly troubleshoot the abnormal cause.

[0091] One application scenario of the present application is that the test process is running on the test terminal device, and the test process is stopped. In some embodiments, the test process is periodically frozen by the CRIU tool during the running of the test process. Accordingly, in S203, when the test terminal device is stopped, the preset processing strategy corresponding to the type of the stop is used to process the stop, and the specific implementation is that when the test terminal device is stopped, the test process is restored by the CRIU tool according to the last frozen process state; the current running graphic service process is terminated, and the current desktop environment type is determined; and a new graphic service process is created according to the desktop environment type.

[0092] The freezing period can be set according to actual needs, for example, 10 minutes, 20 minutes, etc., and the present application does not limit this.

[0093] The present application establishes a test process breakpoint continuation mechanism through the process recovery function of the CRIU tool, periodically freezes the process state of the test process, and when a false stop occurs, the test process can be restored according to the previously frozen process state, so that retesting is not required, the test time is saved, the test efficiency is improved, and the test progress deviation caused by the stop is reduced.

[0094] When the false stop occurs, the GUI is stuck, which indicates that the currently running graphic service process may be dead. By terminating the graphic service process and creating a new graphic service process, the graphic service is hot restarted, the GUI can be quickly restored, and the device does not need to be restarted. Illustratively, the graphic service is an Xorg service (a kind of display server software).

[0095] The desktop environment type is the type to which the current desktop environment belongs. Illustratively, an environment variable is used to determine the currently used desktop environment, and this variable is set by the desktop environment when it is started, and is used to indicate the current desktop environment type. When creating a new graphic service process, an image service process corresponding to the desktop environment type needs to be created.

[0096] In some embodiments, freezing the process state of the test process includes collecting state information of the test process; the state information includes memory data, file descriptors, and register states of the test process; and the state information is saved to a checkpoint directory. Illustratively, the state information is compressed into a compressed package by an LZ4 compression algorithm, and is saved to the checkpoint directory. The LZ4 compression algorithm is a high-performance lossless data compression algorithm.

[0097] Correspondingly, the user space checkpoint / resume tool resumes the test process according to the last frozen process state, including: loading the last frozen process state from the checkpoint directory; recreating a new test process and controlling the newly created test process to continue execution from the last frozen process state.

[0098] Optionally, the CRIU tool freezes the state information of the test process and uploads it to a Network File System (NFS) for shared storage. The CRIU tool also automatically generates checkpoints every 10 minutes for incremental saving. In addition, the CRIU tool performs process recovery in response to a fake downtime signal.

[0099] Thanks to the checkpoint and recovery mechanism of the CRIU tool, the progress deviation during process recovery can be reduced, and the accuracy and efficiency of recovery can be improved.

[0100] Using the CRIU tool for process recovery, the process state is frozen and restored in the user space, while the kernel is used to accurately save the offset of the file descriptor and perform CRC32 check on the memory state, thereby realizing the process breakpoint continuation mechanism and reducing the test progress deviation. This method is suitable for services and applications that require high availability, as it can quickly recover when a process fails and reduce service interruption time. CRC32 (Cyclic Redundancy Check 32) is a 32-bit check code based on the Cyclic Redundancy Check (CRC) algorithm.

[0101] For example, in a Serial Advanced Technology Attachment Hard Disk Drive (SATA HDD) compatibility test, if the Xorg service is dead due to a defective drive, for example, the mouse event loss duration is 8s and the switching delay of the number lock key is 120ms, then the fake downtime is determined, the decision engine generates a fake downtime signal, and triggers the preset processing strategy corresponding to the fake downtime. Specifically, the CRIU tool is used to resume the test process and hot restart the graphics service. This realizes fast continuation of the test and reduces the downtime processing time.

[0102] The determination and processing process of the real downtime are described below.

[0103] In some embodiments, in the case that the state of the test-end device includes a power state, the monitored state data includes power state related data. The monitoring of the state of the test-end device in S201 includes monitoring the power state of the test-end device by a baseboard management controller (BMC). Correspondingly, the determining of whether the test-end device has crashed and the determining of the crash type according to the monitored state data in S202 includes, in the case that the power state related data indicates that the power of the test-end device is abnormal, determining that the test-end device has crashed and determining that the crash type is a true crash.

[0104] On the contrary, in the case that the power state related data indicates that the power of the test-end device is normal, it is indicated that the test-end device is not a true crash, and no processing is performed.

[0105] The way of determining whether the test-end device has a true crash by the power state is relatively accurate.

[0106] In some embodiments, in the case that the state of the test-end device includes a kernel state, the monitored state data includes kernel state related data. The monitoring of the state of the test-end device in S201 includes periodically sending a network connectivity check command to the kernel. In the case that the response to the network connectivity check command is timed out, the kernel state related data is determined to be kernel network abnormal. Correspondingly, the determining of whether the test-end device has crashed and the determining of the crash type according to the monitored state data in S202 includes, in the case that the kernel state related data is kernel network abnormal, determining that the test-end device has crashed and determining that the crash type is a true crash.

[0107] Exemplarily, the network connectivity check command is a ping command. The ping command is a command provided by a Linux system for checking whether a network interface responds, and the ping command can reflect the network processing capability of the kernel. If the ping command can be executed normally and returns a result, it is indicated that the network subsystem of the kernel works normally, and it can be determined that the kernel network is normal. If the ping command is timed out, it means that the expected response is not received within a specific time, which can be caused by network disconnection, unreachability of the test-end device or no response of the kernel of the test-end device to the network request, and it can be determined that the kernel network is abnormal.

[0108] The way of determining whether the test-end device has a true crash by the kernel state is relatively fast.

[0109] In actual applications, whether a true crash occurs can be determined according to the power state, whether a true crash occurs can be determined according to the memory state, and whether a true crash occurs can be determined in combination of the power state and the memory state.

[0110] In some embodiments, in the case of a crash of the test end device in S203, according to the preset processing strategy corresponding to the type of the crash, the crash is processed, including: in the case of a true crash of the test end device, activating the PLP mode of the SSD; through the capacitor power supply window of the SSD, using the direct memory access (Direct Memory Access, DMA) mode to store the data in the memory into the NAND flash memory of the SSD; the data in the memory includes the value of the test port designated register; after the storage is completed, a shutdown operation is performed, and logs are uploaded to a remote server.

[0111] wherein, the NAND flash memory refers to a NAND flash memory, and the NAND flash memory belongs to a kind of nonvolatile storage medium.

[0112] wherein, the length of the capacitor power supply window is determined by a solid state drive (Solid State Drive, SSD), for example, 500ms.

[0113] Exemplarily, using the capacitor power supply window, the key data in the memory is directly DMA transmitted to the NAND flash memory, and the source address is 0xFFFF0-0x1FFFF. Wherein, DMA is a hardware accelerated data transmission mode, and the efficiency and speed of data transmission are higher.

[0114] Exemplarily, the data is saved in a specific address range of the NAND flash memory, which is reserved for storing key data to ensure that these key data can be quickly found and recovered when the system is restored.

[0115] Through the PLP lightning backup technology, the key data in the memory can be quickly saved to the SSD in the case of a true crash, so as to avoid data loss and improve the reliability and data security.

[0116] Exemplarily, the PLP circuit timing is as follows: at 0ms, the BMC detects power supply anomaly; at 20ms, the PLP mode of the SSD is activated; at 50ms, DMA transmission is initiated (source address: 0xFFFF0-0x1FFFF); at 450ms, data is written to the NAND flash memory; at 480ms, a completion signal is sent to the BMC; at 500ms, a safe shutdown is performed.

[0117] The above timing design conforms to the Non-Volatile Memory Express (NVMe) 1.4 standard, compared with the mode of collecting logs after device restart in the related art, the present application can ensure the integrity of data capture.

[0118] For example, the true shutdown handling process in a power failure scenario includes: if a power anomaly is detected, a PLP backup is initiated: the register states in the critical Central Processing Unit (CPU) are saved, specifically the states of the specified registers on the debug port: EAX=0x78AB, EIP=0x7FFE82C1. After the data backup is complete, a safe shutdown is performed, and encrypted logs are uploaded.

[0119] The aforementioned registers contain the CPU's execution state when power is off, which is crucial for subsequent fault analysis and recovery. Specifically, EAX=0x78AB stores the value of the general-purpose register EAX, which is typically used to store function return values ​​or as operands. EIP=0x7FFE82C1 stores the value of the instruction pointer register EIP, which points to the address of the next instruction to be executed.

[0120] For example, when the BMC detects a power abnormality, it outputs an alarm code, such as alarm code 0xA1 representing a power abnormality.

[0121] Safe shutdown specifically includes shutting down running services and processes, and saving necessary system state information. Logging: Recording the system state and operation logs at the time of the power outage, including register values, memory page data, etc. Encrypted upload: Uploading this log data to a remote server or cloud storage after encryption to ensure data security and integrity, which helps with subsequent fault analysis and system recovery. For example, the fault may be caused by a power management firmware stack overflow.

[0122] In related technologies, when a test device experiences a complete crash (such as a kernel crash or power failure), traditional solutions rely on the BMC (Browser Control Center) to collect fault logs. However, the BMC only captures logs after a reboot, losing the memory or register state at the moment of the crash, resulting in a low rate of preservation of critical data and low data integrity. Furthermore, the time from crash to log generation is long, which cannot meet the needs of high-density testing. In contrast, this application, upon detecting a true crash, utilizes the SSD's PLP (Power Buffer Plane) mode to quickly save critical data in memory to the SSD, thereby avoiding data loss and improving reliability and data security.

[0123] Figure 3 A flowchart illustrating another crash handling method provided in this application is shown below. Figure 3 As shown, the downtime handling method includes: monitoring the status of the test terminal device, determining whether a downtime has occurred through a decision engine, and identifying the downtime type; if it is a true downtime, performing a PLP lightning backup, safely shutting down the device, and generating logs. If it is a false downtime, sequentially restoring the CRIU process, performing a hot restart of the graphics service, and resuming the test.

[0124] In some embodiments, the test-side device is a master node in a multi-node test cluster. For example, the multi-node test cluster is a Redis cluster.

[0125] Correspondingly, in the case of a crash of the test-side device in S203, the crash is handled according to a preset processing strategy corresponding to the type of the crash, including: in the case of a true crash of the test-side device, activating the PLP mode of the SSD; storing data in the memory into the NAND flash of the SSD in the form of DMA through the capacitor power supply window of the SSD; performing a shutdown operation after the storage is completed, and uploading logs to a remote server. The crash handling method provided in the present application further includes: after the test-side device is restarted, recovering the cluster state according to the data in the NAND flash.

[0126] The data in the memory includes cluster state related data, such as a cluster state data structure and a cluster node mapping table.

[0127] It should be noted that when the Sentinel (a tool of Redis) detects that the master node crashes, a node is selected from multiple slave nodes to be promoted to a new master node to ensure the high availability of the cluster.

[0128] After the problem causing the crash is solved, the master node can be restarted. After the master node is restarted, the cluster state is recovered by using the data backed up by the PLP, specifically including recovering the cluster state data structure and the cluster node mapping table.

[0129] The present application can be applied to a multi-node test cluster. In the case of a true crash of the master node, the cluster state can be backed up, so that after the master node is restarted, the cluster state can be quickly recovered according to the backed up data.

[0130] The present application constructs an unattended true / false crash automatic processing scheme for an automated test scenario, and achieves the purposes of capturing on-site data in milliseconds in a true crash, having a small test progress deviation after self-recovery in a false crash, and reducing manual intervention.

[0131] 1. True crash millisecond-level on-site capture: The traditional BMC log scheme only captures data after a restart, resulting in a high loss rate of key registers. The present application reduces the data loss rate.

[0132] 2. False crash second-level self-recovery: The frequency of occurrence of problems such as a graphics service deadlock, an input driver failure, and memory leakage and lag is high. The traditional manual disposal scheme takes a long time. The present application realizes the automatic processing of a false crash, shortens the processing time, and further shortens the test interruption time caused by a crash.

[0133] 3、The application breaks through the bottleneck of test progress zero caused by whole machine restart, and realizes test fast continuous running.

[0134] In addition to the automatic test scene, the true and false machine discrimination mechanism provided by the application can also be used for industrial controllers, such as programmable logic controllers (PLC).

[0135] Or, it can also be applied to driving scenes. When the vehicle-mounted system has interface freezing (such as a central control screen being stuck), but the underlying program runs normally, it can be determined whether it belongs to false machine according to the response time delay of the steering wheel torque sensor and the gear response time delay, and if it belongs to false machine, the display service is automatically restarted, thereby ensuring driving continuity. For example, if the response time delay of the steering wheel torque sensor and the gear response time delay is greater than the preset response time delay, it is determined that false machine occurs. Otherwise, no processing is performed.

[0136] Through the description of the above embodiments, those skilled in the art can clearly understand that the method according to the above embodiments can be realized by means of software and the necessary general hardware platform, of course, it can also be realized by hardware, but in many cases the former is a better embodiment.

[0137] Figure 4 A structure diagram of a machine crash processing device provided by the application is shown in FIG. 1. As shown in FIG. 1, the machine crash processing device 40 includes the following modules. Figure 4

[0138] The monitoring module 401 is configured to monitor the state of the test terminal device; the state includes user interaction behavior, and the user interaction behavior includes input events of a physical input device; the state also includes at least one of a power state and a kernel state;

[0139] The determining module 402 is configured to determine whether the test terminal device has a machine crash according to the monitored state data, and determine the machine crash type; the machine crash type is true machine crash or false machine crash; the state data includes input event related data; the false machine crash is determined according to the input event related data; the state data also includes at least one of power state related data and kernel state related data; the true machine crash is determined according to at least one of the power state related data and the kernel state related data;

[0140] The processing module 403 is configured to, in the case that the test terminal device has a machine crash, perform machine crash processing according to a preset processing strategy corresponding to the machine crash type; the preset processing strategy corresponding to the true machine crash includes a power-off protection mode of a solid state disk; and the preset processing strategy corresponding to the false machine crash includes a user space checkpoint / recovery tool.

[0141] ​Optionally, the input event comprises a mouse event and a toggle event of a keyboard number lock key; the input event related data comprises a loss duration of the mouse event and a toggle delay of the keyboard number lock key; in the case that the state comprises a user interaction behavior, the monitoring module 401 is specifically configured to: in response to the mouse event trigger, record the number of occurrences of the mouse event and the trigger time of the mouse event, and in response to the keyboard number lock key being pressed, record the toggle delay of the keyboard number lock key, the toggle delay being a time difference between the key press and the change of the state indicator light; periodically detect the trigger time and the toggle delay recorded last time according to a preset sampling rate, and calculate the loss duration of the mouse event; the loss duration is a time difference between the current time and the trigger time; the determining module 402 is specifically configured to: in the case that the loss duration is greater than a preset time threshold and the toggle delay is less than a preset delay threshold, determine that the test terminal device has a downtime, and determine that the downtime type is a false downtime.

[0142] Optionally, the determining module 402 is specifically configured to: in the case that the loss duration is greater than a preset time threshold and the toggle delay is less than a preset delay threshold, send a process state viewing command to the kernel; in the case that the process state viewing command can be executed and a result is returned, determine that the kernel survival state is kernel alive; if it is determined that the kernel survival state is kernel alive, determine that the test terminal device has a downtime, and determine that the downtime type is a false downtime.

[0143] Optionally, the downtime processing apparatus 40 further comprises a freezing module, configured to: periodically freeze the process state of the test process by a user space checkpoint / recovery tool during the running of the test process; accordingly, the processing module 403 is specifically configured to: in the case that the test terminal device has a false downtime, restore the test process according to the process state frozen last time by the user space checkpoint / recovery tool; terminate the currently running graphical service process, and determine the current desktop environment type; according to the desktop environment type, recreate a new graphical service process.

[0144] Optionally, the freezing module, when freezing the process state of the test process, is specifically configured to: collect state information of the test process; the state information comprises memory data, file descriptors and register states of the test process; save the state information into a checkpoint directory; the processing module 403, when restoring the test process according to the process state frozen last time by the user space checkpoint / recovery tool, is specifically configured to: load the process state frozen last time from the checkpoint directory; recreate a new test process, and control the newly created test process to continue execution from the process state.

[0145] Optionally, in the case that the state comprises a power state, the state data comprises power state related data; the monitoring module 401 is specifically configured to monitor the power state of the test end device through the baseboard management controller; and the determining module 402 is specifically configured to determine that the test end device has a downtime and determine that the downtime type is a true downtime in the case that the power state related data indicates that the power of the test end device is abnormal.

[0146] Optionally, in the case that the state comprises a kernel state, the state data comprises kernel state related data; the monitoring module 401 is specifically configured to periodically send a network connectivity check command to the kernel; and the determining module 402 is specifically configured to determine that the test end device has a downtime and determine that the downtime type is a true downtime in the case that a response to the network connectivity check command is timed out.

[0147] Optionally, the processing module 403 is specifically configured to activate a power-off protection mode of the solid state disk in the case that the test end device has a true downtime; store data in the memory into NAND flash of the solid state disk in a direct memory access manner through a capacitor power supply window of the solid state disk; the data comprises values of test port designated registers; perform a shutdown operation after the storage is completed, and upload logs to a remote server.

[0148] Optionally, the test end device is a master node in a multi-node test cluster; and the processing module 403 is specifically configured to activate a power-off protection mode of the solid state disk in the case that the test end device has a true downtime; store data in the memory into NAND flash of the solid state disk in a direct memory access manner through a capacitor power supply window of the solid state disk; the data comprises a cluster state data structure and a cluster node mapping table; perform a shutdown operation after the storage is completed, and upload logs to a remote server; and restore the cluster state according to the data in the NAND flash after the test end device is restarted.

[0149] The features of the embodiment corresponding to the downtime processing apparatus 40 can be referred to the related descriptions of the embodiments of the downtime processing method, which will not be repeated here.

[0150] The present application also provides an electronic device, which can be the test end device described above.

[0151] Figure 5 A structural schematic diagram of an electronic device provided by the present application is shown in FIG. 5. Figure 5 As shown in FIG. 5, the electronic device 50 provided by the present embodiment comprises a processor 501 and a memory 502. Optionally, the electronic device 50 further comprises a communication component 503. The processor 501, the memory 502 and the communication component 503 are connected through a bus.

[0152] In the implementation process, the processor 501 executes the computer program stored in the memory 502, so that the processor 501 performs the above-mentioned method embodiment of the off-line processing.

[0153] The specific implementation process of the processor 501 can refer to the above-mentioned method embodiments, which have similar implementation principles and technical effects, and details are not described here.

[0154] In the above-mentioned embodiments, it should be understood that the processor can be a central processing unit (CPU), and can also be other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), etc. The general-purpose processor can be a microprocessor or the processor can also be any conventional processor, etc. The steps of the method disclosed in the application can be directly embodied as hardware processor execution, or executed by a combination of hardware and software modules in the processor.

[0155] The memory can contain a random access memory (RAM), and can also include a non-volatile memory (NVM), such as at least one disk memory.

[0156] The bus can be an industry standard architecture (ISA) bus, a peripheral component (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc.

[0157] Embodiments of the application also provide a computer readable storage medium, which stores a computer program, wherein the computer program is configured to execute the steps in any of the above-mentioned method embodiments of the off-line processing when running.

[0158] In an example embodiment, the above-mentioned computer readable storage medium can include, but is not limited to: a U disk, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk or an optical disk, and various media that can store computer programs.

[0159] The embodiment of the present application further provides a computer program product, which comprises a computer program, and the computer program realizes the steps in any of the foregoing crash handling method embodiments when executed by a processor.

[0160] The embodiment of the present application further provides another computer program product, which comprises a nonvolatile computer readable storage medium, and the nonvolatile computer readable storage medium stores a computer program, and the computer program realizes the steps in any of the foregoing crash handling method embodiments when executed by a processor.

[0161] It should be noted that, for the foregoing method embodiments, in order to simply describe, each is described as a combination of a series of actions, but those skilled in the art should know that the present application is not limited to the order of the actions described, because according to the present application, certain steps can be performed in other order or simultaneously. Secondly, those skilled in the art should know that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily required by the present application.

[0162] It should be further noted that, although each step in the flowchart is displayed in sequence according to the arrow, these steps are not necessarily executed in sequence according to the arrow. Unless explicitly stated in this article, the execution of these steps has no strict order limit, and these steps can be executed in other order. Moreover, at least part of the steps in the flowchart can include multiple sub-steps or multiple stages, which are not necessarily executed at the same time, but can be executed at different times, and the execution order of these sub-steps or stages is not necessarily sequential, but can be alternately executed with other steps or sub-steps or stages of other steps.

[0163] In the foregoing embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments. The technical features of the foregoing embodiments can be combined arbitrarily, and in order to make the description brief, the possible combinations of the technical features in the foregoing embodiments are not described, however, as long as the combinations of the technical features do not exist contradictions, they should be considered as the scope of the present application.

[0164] It should be understood that the foregoing apparatus embodiments are only illustrative, and the apparatus of the present application can also be realized by other manners. For example, the division of units / modules in the foregoing embodiments is only a logical function division, and another division manner can be used in actual implementation. For example, multiple units, modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed.

[0165] In addition, each functional unit / module in each embodiment of the present application can be integrated in one unit / module, or each unit / module can exist physically, or two or more units / modules can be integrated together. The integrated unit / module can be realized in the form of hardware or in the form of a software program module.

[0166] Those skilled in the art will further appreciate that the functions of the examples described herein-based embodiments can be implemented using electronic hardware, computer software, or any combination thereof. To clearly illustrate this interchangeability of hardware and software, various examples have been described herein generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the particular application and design constraints imposed on the overall system. Skilled artisans can implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

[0167] The above provides a kind of machine processing method and electronic equipment provided by the present application in detail. The principle and implementation of the present application are described in this paper by applying specific examples, the above example is only used to help understand the method and its core idea of the present application. It should be pointed out that, for the ordinary skilled person in the art, without departing from the principle of the present application, some improvements and modifications can be made to the present application, and these improvements and modifications also fall within the protection scope of the claims of the present application.

Claims

1. A method of handling a crash, characterized by, The method comprises the following steps: monitoring the state of a test terminal device; the state comprises user interaction behavior, the user interaction behavior comprising input events of a physical input device; the state further comprises at least one of a power state and a kernel state; the input events comprise mouse events and switching events of a keyboard number lock key; determining whether the test terminal device has a crash according to monitored state data, and determining a crash type; the crash type is a true crash or a false crash; the state data comprises input event related data; the input event related data comprises a loss duration of the mouse events and a switching delay of the keyboard number lock key; the loss duration is a time difference between a current time and a triggering time of the last recorded mouse event; the switching delay is a time difference between a key press of the keyboard number lock key and a change of a state indicator light; the false crash is determined in the case that the loss duration is greater than a preset time threshold and the switching delay is less than a preset delay threshold; the state data further comprises at least one of power state related data and kernel state related data; the true crash is determined according to at least one of the power state related data and the kernel state related data; in the case that the test terminal device has a crash, performing a crash processing according to a preset processing strategy corresponding to the crash type; the preset processing strategy corresponding to the true crash comprises a power-off protection mode of a solid state disk; the preset processing strategy corresponding to the false crash comprises a user space checkpoint / recovery tool.

2. The method of claim 1, wherein, The method further comprises the following steps: in response to a triggering of the mouse event, recording a number of occurrences of the mouse event and a triggering time of the mouse event, and in response to the keyboard number lock key being pressed, recording a switching delay of the keyboard number lock key; periodically detecting the triggering time and the switching delay recorded last according to a preset sampling rate, and calculating a loss duration of the mouse event; the step of determining whether the test terminal device has a crash according to monitored state data, and determining a crash type, comprises the following steps: in the case that the loss duration is greater than a preset time threshold and the switching delay is less than a preset delay threshold, determining that the test terminal device has a crash, and determining that the crash type is a false crash.

3. The method of claim 2, wherein, the step of determining whether the test terminal device has a crash according to monitored state data, and determining a crash type, comprises the following steps: in the case that the loss duration is greater than a preset time threshold and the switching delay is less than a preset delay threshold, sending a process state viewing command to a kernel; in the case that the process state viewing command can be executed and returns a result, determining a kernel survival state as kernel survival; if it is determined that the kernel survival state is kernel survival, then determining that the test terminal device has a crash, and determining that the crash type is a false crash.

4. The method of claim 1 or 2, wherein, The method further comprises the following steps: periodically freezing a process state of a test process by the user space checkpoint / recovery tool during a running process of the test process; The crash processing is performed according to a preset processing strategy corresponding to the crash type in the case that the test terminal device crashes. In the case that the test terminal device crashes, the test process is resumed by the user space checkpoint / resume tool according to the process state frozen last time. Terminate the currently running graphic service process, and determine the current desktop environment type. According to the desktop environment type, a new graphic service process is recreated.

5. The method of claim 4, wherein, Freezing the process state of the test process, comprising: Collecting state information of the test process; the state information comprises memory data, file descriptor and register state of the test process; Saving the state information into a checkpoint directory; The test process is resumed by the user space checkpoint / resume tool according to the process state frozen last time, comprising: Loading the process state frozen last time from the checkpoint directory; Recreating a new test process, and controlling the newly created test process to continue execution from the process state.

6. The method of claim 1, wherein, In the case that the state comprises the power state, the state data comprises power state related data; the state of the test terminal device is monitored, comprising: Monitoring the power state of the test terminal device by a baseboard management controller; The test terminal device is determined to crash and the crash type is determined according to the monitored state data, comprising: In the case that the power state related data indicates that the power of the test terminal device is abnormal, it is determined that the test terminal device crashes, and the crash type is determined as true crash.

7. The method of claim 1, wherein, In the case that the state comprises the kernel state, the state data comprises kernel state related data; The state of the test terminal device is monitored, comprising: Periodically sending a network connectivity check command to the kernel; The test terminal device is determined to crash and the crash type is determined according to the monitored state data, comprising: In the case that the response to the network connectivity check command is timed out, it is determined that the test terminal device crashes, and the crash type is determined as true crash.

8. The method of claim 6 or 7, wherein, The crash processing is performed according to a preset processing strategy corresponding to the crash type in the case that the test terminal device crashes, comprising: In the case that the test terminal device crashes, the power-off protection mode of the solid state disk is activated; Through the capacitor power supply window of the solid state disk, data in the memory is stored into the NAND flash memory of the solid state disk in a direct memory access mode; the data comprises the value of the test port specified register; After the storage is completed, a shutdown operation is performed, and logs are uploaded to a remote server.

9. The method of claim 6 or 7, wherein, The test terminal device is a master node in a multi-node test cluster; The crash processing is performed according to a preset processing strategy corresponding to the crash type in the case that the test terminal device crashes, comprising: In the case that the test terminal device crashes, the power-off protection mode of the solid state disk is activated; The data in the memory is stored into the NAND flash memory of the solid state disk by a direct memory access mode through a capacitor power supply window of the solid state disk; the data includes a cluster state data structure and a cluster node mapping table; A shutdown operation is performed after the storage is completed, and logs are uploaded to a remote server; The method further comprises: After the test terminal device is restarted, the cluster state is recovered according to the data in the NAND flash memory.

10. An electronic device, comprising: Comprise: A memory for storing a computer program; A processor for executing the computer program to implement the steps of the method for handling a crash according to any one of claims 1 to 9.

Images