Process keep-alive method and device, computer equipment, storage medium and program product

Abstract

The invention relates to a process keep-alive method and device, computer equipment, a storage medium and a program product. The method comprises the steps that under the condition that it is determined that a monitoring process is started, the front state of a to-be-monitored process is determined; the to-be-monitored process is a process in a process group corresponding to a cluster system; the monitoring process is a process used for monitoring the running state of the process to be monitored; if the pre-state of the to-be-monitored process is a preset state, executing a corresponding process keep-alive operation on the to-be-monitored process; and after the process keep-alive operation is executed, determining the post state of the process to be monitored based on the received new process group event and a process state machine. By adopting the method, the cluster thread can be kept alive timely and accurately.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a process keep-alive method, apparatus, computer equipment, storage medium, and program product. Background Technology

[0002] With increasing demands for data processing capabilities and cluster system stability, ensuring the continuous operation and rapid recovery of processes within a cluster system has become crucial. However, processes in a cluster system may unexpectedly terminate due to software defects, hardware failures, or network problems, leading to service interruptions and impacting user experience and business operations.

[0003] In traditional technologies, process protection mechanisms are mostly based on "periodic reporting." If the reporting thread is normal, but the cluster process fails, the cluster process will still be mistakenly considered normal. Therefore, traditional technologies have the problem of not being able to keep cluster threads alive in a timely and accurate manner. Summary of the Invention

[0004] Therefore, it is necessary to provide a process keep-alive method, device, computer equipment, storage medium, and program product that can keep cluster threads alive in a timely and accurate manner to address the above-mentioned technical problems.

[0005] Firstly, this application provides a process keep-alive method, including:

[0006] Once it is determined that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0007] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation is performed on the process to be monitored.

[0008] After the process keep-alive operation is completed, the post-state of the process to be monitored is determined based on the received new process group event and process state machine.

[0009] In the process keep-alive method, after the controller is started, the monitoring process is pulled up, the process state of the to-be-monitored process is written into the local panel when the to-be-monitored process can perform the pulling up for the monitoring process, and therefore, in the case of determining that the monitoring process is started, the pre-state of the to-be-monitored process can be determined in time, the time delay of process state identification is reduced, and therefore, when the pre-state of the to-be-monitored process is the preset state, the corresponding process keep-alive operation can be performed on the to-be-monitored process in time and accurately, the delay of fault sensing is avoided, the fault response time is shortened, and after the process keep-alive operation is performed, the post-state of the to-be-monitored process can be determined based on the newly received process group event and process state machine, and the continuous operation of the to-be-monitored process is ensured.

[0010] In one of the embodiments, the preset state includes an unready and non-stuck state and a stuck state, and if the pre-state of the to-be-monitored process is the preset state, the corresponding process keep-alive operation is performed on the to-be-monitored process, including:

[0011] If the pre-state is the unready and non-stuck state, a pulling up operation is performed on the to-be-monitored process.

[0012] If the pre-state is the stuck state, process hanging detection is performed on the to-be-monitored process, and after the hanging detection is completed, a pulling up operation is performed on the to-be-monitored process.

[0013] In one of the embodiments, the pulling up operation performed on the to-be-monitored process includes:

[0014] Reading a configuration file of the to-be-monitored process.

[0015] Based on the configuration file, the pulling up operation is performed on the to-be-monitored process.

[0016] In the embodiment, by reading the configuration file of the to-be-monitored process, the operation information of the pulling up operation performed on the to-be-monitored process can be accurately obtained based on the configuration file of the to-be-monitored process, the accuracy of the pulling up operation performed on the to-be-monitored process is ensured, and the process pulling up success rate is improved.

[0017] In one of the embodiments, the reading of the configuration file of the to-be-monitored process includes:

[0018] The configuration file is read from the shared memory, and if the configuration file is not read from the shared content, the configuration file is read from the hard disk.

[0019] In the embodiment, if the configuration file is not read from the shared content, the configuration file is read from the hard disk, and the operation of the high-availability module accessing the disk can be reduced as much as possible.

[0020] In one of the embodiments, the process hang-up detection on the to-be-monitored process comprises:

[0021] If the to-be-monitored process is a storage-side process or a protocol-side process, the process hang-up detection on the to-be-monitored process is performed through a pulse clock mechanism based on a scheduling round refresh.

[0022] If the to-be-monitored process is a management-side process, the process hang-up detection on the to-be-monitored process is performed based on a heartbeat mechanism.

[0023] In the embodiment, if the to-be-monitored process is a storage-side process or a protocol-side process, the process hang-up detection on the to-be-monitored process is performed through a pulse clock mechanism based on a scheduling round refresh, and if the to-be-monitored process is a management-side process, the process hang-up detection on the to-be-monitored process is performed based on a heartbeat mechanism. Differentiated hang-up detection mechanisms are adopted for different types of to-be-monitored processes, which can adapt to the running environment constraints and technical characteristics of different to-be-monitored processes, and can take into account system stability, compatibility and keep-alive efficiency while ensuring detection accuracy.

[0024] In one of the embodiments, the determination of the post-state of the to-be-monitored process based on the received new process group event and the process state machine comprises any of the following:

[0025] If the new process group event is a group-in event of the to-be-monitored process or a pulse push of the to-be-monitored process, the post-state of the to-be-monitored process is determined as a ready state.

[0026] If the new process group event is a group-out event of the to-be-monitored process, the post-state of the to-be-monitored process is determined as an unready state.

[0027] If the new process group event is a pulse stall of the to-be-monitored process, the post-state of the to-be-monitored process is determined as a dead state.

[0028] In one of the embodiments, if the pre-state of the to-be-monitored process is a ready state, the method further comprises:

[0029] If a group-out event of the to-be-monitored process is received, the post-state of the to-be-monitored process is determined as an unready state; or,

[0030] If a pulse stall of the to-be-monitored process is detected, the post-state of the to-be-monitored process is determined as a dead state.

[0031] In the embodiment, when the pre-state of the to-be-monitored process is the ready state, if a retreat event of the to-be-monitored process is received, it is determined that the post-state of the to-be-monitored process is the unready state; or if the pulse stagnation of the to-be-monitored process is detected, it is determined that the post-state of the to-be-monitored process is the dead state. Through the above process, for different trigger conditions, the determined post-state is also different, and different post-states can realize accurate classification and low-delay response of the fault of the to-be-monitored process.

[0032] In one of the embodiments, the method further comprises:

[0033] The process for processing the process keep-alive method is hung up and detected through an interface provided by a hardware watchdog driver.

[0034] In the embodiment, the process for processing the process keep-alive method can be hung up and detected through an interface provided by a hardware watchdog driver, so that the fault of the process for processing the process keep-alive method can be processed in time, and the continuous interruption of the process joining and process keep-alive processing is avoided.

[0035] In one of the embodiments, the method further comprises:

[0036] The state transition information of the to-be-monitored process is recorded in a memory board of shared memory.

[0037] In the embodiment, the state transition information of the to-be-monitored process can be recorded and displayed through the memory board of shared memory, and the state transition information of the to-be-monitored process is recorded in the memory board of shared memory, so that the state data of the to-be-monitored process is always consistent with the keep-alive logic of the high-availability module, and the problem that the keep-alive strategy is executed incorrectly due to the misoperation of an external module is avoided.

[0038] In a second aspect, the application further provides a process keep-alive device, comprising:

[0039] A first determination module is configured to determine a pre-state of a to-be-monitored process when a monitoring process is started, wherein the to-be-monitored process is a process in a process group corresponding to a cluster system, and the monitoring process is a process for monitoring the running state of the to-be-monitored process;

[0040] A keep-alive module is configured to perform a corresponding process keep-alive operation on the to-be-monitored process if the pre-state of the to-be-monitored process is a preset state.

[0041] A second determination module is configured to determine a post-state of the to-be-monitored process based on a new process group event and a process state machine received after the process keep-alive operation is performed.

[0042] Thirdly, this application also provides a computer device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0043] Once it is determined that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0044] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation is performed on the process to be monitored.

[0045] After the process keep-alive operation is completed, the post-state of the process to be monitored is determined based on the received new process group event and process state machine.

[0046] Fourthly, this application also provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, performs the following steps:

[0047] Once it is determined that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0048] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation is performed on the process to be monitored.

[0049] After the process keep-alive operation is completed, the post-state of the process to be monitored is determined based on the received new process group event and process state machine.

[0050] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, performs the following steps:

[0051] Once it is determined that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0052] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation is performed on the process to be monitored.

[0053] After the process keep-alive operation is completed, the post-state of the process to be monitored is determined based on the received new process group event and process state machine.

[0054] The aforementioned process keep-alive method, device, computer equipment, storage medium, and program product, after the controller starts, the monitoring process is started, and the process to be monitored can be started. The process state of the process to be monitored is written into the local dashboard. Therefore, when it is determined that the monitoring process has started, the previous state of the process to be monitored can be determined in a timely manner, reducing the latency of process state identification. Thus, when the previous state of the process to be monitored is a preset state, the corresponding process keep-alive operation can be performed on the process to be monitored in a timely and accurate manner, avoiding the delay in fault perception, shortening the fault response time, and after the process keep-alive operation is completed, the subsequent state of the process to be monitored can be determined based on the newly received process group event and process state machine, ensuring the continuous operation of the process to be monitored. Attached Figure Description

[0055] To more clearly illustrate the technical solutions in the embodiments of this application or related technologies, the drawings used in the description of the embodiments of this application or related technologies will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0056] Figure 1 This is a flowchart illustrating a process keep-alive method in one embodiment;

[0057] Figure 2 This is a schematic diagram of the overall structure of a process high availability module in one embodiment;

[0058] Figure 3 This is a flowchart illustrating the process of business process fault detection in one embodiment;

[0059] Figure 4 This is a schematic diagram of the process state machine in one embodiment;

[0060] Figure 5 This is a flowchart illustrating the process keep-alive method in another embodiment;

[0061] Figure 6 This is a flowchart illustrating the process keep-alive method in another embodiment;

[0062] Figure 7 This is a structural block diagram of a process keep-alive device in one embodiment;

[0063] Figure 8 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0064] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0065] In one exemplary embodiment, such as Figure 1 As shown, a process keep-alive method is provided. This embodiment illustrates the method by applying it to a computer device. It is understood that this method can also be applied to a server, and to a system including both a computer device and a server, and is implemented through the interaction between the computer device and the server. In this embodiment, the method includes the following steps:

[0066] S201, if the monitoring process is determined to be started, determine the current state of the process to be monitored; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0067] The process to be monitored is a process in the process group corresponding to the cluster system. For example, the process to be monitored can be any of the following: storage-side process, management-side process, and protocol-side process.

[0068] First, it should be noted that the process keep-alive method proposed in this application can be executed by a process high availability module (PHA). In this embodiment, the monitoring process can be a PHA process, as an example. Figure 2 This is a schematic diagram of the overall structure of the process high availability module. The process high availability module can be classified as a high availability process. The process keep-alive function can be handled by the kernel module, and the process keep-alive function is performed by a single thread.

[0069] In this embodiment, group management is responsible for monitoring the status of high-availability processes and restarting high-availability processes after they have been suspended. The keep-alive mechanism for protocol-side processes, storage-side processes, and the local agent (StarMA, MA) of the management service process on the management side is achieved through groups and pulse clock functionality based on scheduling rounds. The keep-alive mechanism for management service processes (StarMS, MS), hardware status collection processes (StarMH, MH), NGINX, and other processes on the management side is achieved through groups and management-side heartbeats.

[0070] For example, the pre-state of the process to be monitored may include an off state, a ready state, and a hung state, etc. As an optional implementation, in this embodiment, the pre-state of the process to be monitored can be determined by the high availability module based on the received process group event after the process to be monitored is added to the process group. The process group event can be obtained by the user-space process by querying the kernel-space process group and then sent to the high availability module based on a callback.

[0071] Figure 3 A flowchart illustrating a business process fault detection method is shown. In this embodiment, as follows: Figure 3 As shown, typically, when the cluster starts or the controller powers on, all monitored processes under the care of the process high availability module are in the Off state. After a monitored process starts and joins the process group, a group joining event is triggered, and the monitored process enters the Ready state. If a monitored process abnormally terminates while in the Ready state due to software defects, hardware failures, resource exhaustion, or other reasons, the user-space process can send a process group event to the process high availability module via callback to notify the module that the monitored process has terminated. The process high availability module then updates the monitored process's state from Ready to Off. If a monitored process exists with a PID (Process ID) but its business logic is stuck while in the Ready state, the process high availability module, upon receiving the process group event sent by the user-space process via callback, can update the monitored process's state from Ready to Hung.

[0072] S202, if the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation is performed on the process to be monitored.

[0073] For example, the preset states in this embodiment may include a not-ready and non-zombie state and a zombie state. In this embodiment, as an optional implementation, when the cluster starts or the controller powers on, if the pre-state of the process to be monitored is Off, the process high availability module can execute a pull-up script to perform a pull-up operation on the process to be monitored, driving the process to be monitored to start and join the process group to keep the process alive. Further, when the process to be monitored is in the Ready state, if it exits abnormally due to software defects, hardware failures, resource exhaustion, etc., the process high availability module will update the state of the process to be monitored from Ready to Off, and then trigger a pull-up operation to restart the process to be monitored and rejoin the group. In addition, when the process to be monitored is in the Ready state, if the process to be monitored has a PID but the business logic is stuck, that is, the process to be monitored is in the Hung state, the process high availability module can perform process hang detection on the process to be monitored, execute a kill operation on the process to be monitored, and after the hang detection is completed and it is determined that the state of the process to be monitored has changed to the not-ready state, perform a pull-up operation on the process to keep the process alive.

[0074] If the process to be monitored has not been started, after the start-up operation is completed, the callback registered by the high availability module will be executed in the group's thread after the process starts normally. In this callback, the process to be monitored can be quickly triggered to transition to the Ready state. If the process to be monitored has already started, it will not enter the group callback after the start-up operation is completed. It needs to periodically schedule and query the pulse push (storage-side process) or heartbeat (management-side process) to transition to the Ready state.

[0075] S203, after performing the process keep-alive operation, determines the post-state of the process to be monitored based on the received new process group event and process state machine.

[0076] In this embodiment, to avoid coupling with the group process state machine, the process state machine can be designed with three states: Off state: representing that the process is in an unready state and needs to be restarted; Ready state: representing that the process is in a ready state; Hung state: representing that the process is in a zombie state. Figure 4 A schematic diagram of the process state machine is shown. For a description of the process state machine's transitions, please refer to Table 1 below.

[0077] Table 1

[0078] Serial number Preceding state Action description Subsequent state E1 Off When the process is in Off state, pull-up operation is performed on it, after each pull-up, check if the group-in event is received, if so, determine that the pull-up is successful, and the process state enters Ready state Ready E2 Off When the process is in Off state, pull-up operation is performed on it, after each pull-up, check if the pulse push of the process is received, if so, determine that the pull-up is successful, and the process state enters Ready state Ready E3 Off When the process is in Off state, pull-up operation is performed on it, after each pull-up, the group-out event of the process is received, then determine that the pull-up fails, and the process state enters Off state Off E4 Off When the process is in Off state, pull-up operation is performed on it, after each pull-up, the group-in, group-out event and pulse push (E1, E2, E3) of the process are checked, until the pulse stall is checked, then enter Hung state Hung E5 Ready When the process is in Ready state, the PHA receives the group-out event of the process, then the process state enters Off state Off E6 Ready When the process is in Ready state, the PHA checks the pulse stall of the process, then the process state enters Off state Hung E7 Hung When the process is in Hung state, the PHA performs kill operation on it, then the process exits, which triggers the group-out event, and after the group-out, it enters Off state Off

[0079] After performing a keep-alive operation on the process to be monitored, the user-space process can send a new process group event to the process high availability module. The process high availability module can determine the subsequent state of the process to be monitored based on the received new process group event and the flow information in the process state machine, ensuring the continuous operation of the process to be monitored. Please refer to the description in Table 1 above. As an optional implementation method, when the previous state of the process to be monitored is Off, the process high availability module periodically performs a start-up operation on the process to be monitored. After the start-up operation, if the received new process group event is a detection of the process to be monitored joining the group or a detection of the pulse push of the process to be monitored, then the subsequent state of the process to be monitored is determined to be Ready. If the received new process group event is a detection of the process to be monitored leaving the group, then the start-up is determined to have failed, and the subsequent state of the process to be monitored is determined to be Off. If the received new process group event is a detection of the pulse stagnation of the process to be monitored, then the subsequent state of the process to be monitored is determined to be Zombie. After the Zombie state, the process core dump information is saved. After saving, the process leaves the group, the flag is set to Off, and the start-up is performed. The process for determining the post-state of the process to be monitored, based on different pre-states, process group events, and process state machines, can be found in the description in Table 1 above. This embodiment will not explain them one by one here.

[0080] In the above process keep-alive method, after the controller starts, the monitoring process is started, and the process to be monitored can be started by the monitoring process. The process status of the process to be monitored is written into the local dashboard. Therefore, when it is determined that the monitoring process has started, the previous state of the process to be monitored can be determined in a timely manner, reducing the latency of process status identification. Thus, when the previous state of the process to be monitored is the preset state, the corresponding process keep-alive operation can be performed on the process to be monitored in a timely and accurate manner, avoiding the delay in fault perception and shortening the fault response time. After the process keep-alive operation is completed, the subsequent state of the process to be monitored can be determined based on the newly received process group event and process state machine, ensuring the continuous operation of the process to be monitored.

[0081] This embodiment explains the specific implementation process of the process to be monitored performing a pull-up action. In an exemplary embodiment, such as... Figure 5 As shown, the above-mentioned "execute pull-up action for the process to be monitored" includes:

[0082] S301 reads the configuration file of the process to be monitored.

[0083] In this embodiment, process keep-alive is configurable. Keep-alive operations are only performed on processes specified in the configuration. Before executing the start-up action on the process to be monitored, the autorun configuration file of the process to be monitored can be read first. As an optional implementation, the configuration file can be read from shared memory first. If the configuration file does not exist in the shared memory, it indicates that the MS service has not been configured, and the configuration file is then read from the hard disk, minimizing disk access operations by the high availability module.

[0084] S302, based on the configuration file, performs a start-up operation on the process to be monitored.

[0085] As an optional implementation, the configuration file can record key information required for the monitored process to perform the start-up operation, such as the startup script path, startup parameters (such as port number and log path), and dependent resource paths of the monitored process. This ensures that the process high availability module can directly call the correct script and parameters to start the process, and / or the keep-alive strategy of the monitored process, such as a 5-second retry interval after the management-side process fails to start up, and a 3-second retry interval for the storage-side process. This ensures that the process high availability module executes differentiated keep-alive logic for different types of processes, which meets the cluster's availability requirements for different processes.

[0086] In this embodiment, by reading the configuration file of the process to be monitored, the operation information when the process to be monitored is pulled up can be accurately obtained based on the configuration file, which ensures the accuracy of the pull-up operation performed on the process to be monitored and improves the success rate of process pull-up.

[0087] When a monitored process hangs, the process high availability module needs a corresponding detection mechanism to identify it, perform a kill operation, and then restart the process to restore its functionality. The process high availability module is only responsible for scheduling-level hang detection; for business-level task hangs, higher-level module detection is required. The detailed process of detecting process hangs in the monitored process will be explained below. In an exemplary embodiment, such as... Figure 6 As shown, the above-mentioned "process hang detection for the process to be monitored" includes:

[0088] S401 If the process to be monitored is a storage-side process or a protocol-side process, then the process hang detection is performed on the process to be monitored through a pulse clock mechanism based on scheduling round refresh.

[0089] In this embodiment, if the process to be monitored is a storage-side process or a protocol-side process, a pulse clock mechanism based on scheduling round refresh can be used to detect process hangs. As an example, the creator of the pulse key-value items in the dashboard is a process, and its lifecycle begins when the process is first started and ends when the controller is powered down. The clock pulses need to cover all critical threads within the process.

[0090] S402, if the process to be monitored is a management process, then based on the heartbeat mechanism, process hang detection is performed on the process to be monitored.

[0091] In this embodiment, since most management layer processes cannot use memory dashboards and process-level clock pulse mechanisms, the same mechanism as the protocol side and storage side cannot be used for process hang detection of management-side processes. As an optional implementation, when the process to be monitored is a management-side process, process hang detection can be performed based on memory file heartbeats. The detection timing diagram can be as follows: Figure 7 As shown, for example, MS, MH, etc. each update the / dev / shm / hb value, and PHA directly queries the information to perform hang detection of the process to be monitored.

[0092] In this embodiment, if the process to be monitored is a storage-side process or a protocol-side process, a pulse clock mechanism based on scheduling round refresh is used to detect process hang-ups. If the process to be monitored is a management-side process, a heartbeat mechanism is used to detect process hang-ups. Differentiated hang-up detection mechanisms are adopted for different types of processes to be monitored, which can adapt to the operating environment constraints and technical characteristics of different processes to be monitored. While ensuring detection accuracy, system stability, compatibility and keep-alive efficiency can also be taken into account.

[0093] The above embodiments describe examples where the preceding state of the process to be monitored is an unready state and a zombie state. This embodiment describes and explains the relevant embodiments when the preceding state of the process to be monitored is a ready state. In an exemplary embodiment, the above method further includes: if a group-leaving event of the process to be monitored is received, then determining that the subsequent state of the process to be monitored is an unready state; or, if a pulse stagnation of the process to be monitored is detected, then determining that the subsequent state of the process to be monitored is a zombie state.

[0094] In this embodiment, please continue to refer to the process state machine flow description in Table 1 above. When the preceding state of the process to be monitored is the ready state, if a leave event of the process to be monitored is received, it can be determined that the following state of the process to be monitored is the not-ready state. As another optional implementation, when the preceding state of the process to be monitored is the ready state, if a pulse stagnation of the process to be monitored is detected, it can be determined that the following state of the process to be monitored is the dead state.

[0095] In this embodiment, if a process to be monitored is received as a pre-state of ready, and a process to be monitored leaves the group, then the post-state of the process to be monitored is determined to be a not-ready state; or, if a pulse stagnation of the process to be monitored is detected, then the post-state of the process to be monitored is determined to be a dead state. Through the above process, the post-state determined for different triggering conditions is also different. Different post-states can achieve accurate classification of faults in the process to be monitored and low-latency response.

[0096] This embodiment will explain and illustrate the implementation of the hanging detection of the process (i.e., the high-availability process) itself that handles the above process keep-alive method. In an exemplary embodiment, the above method further includes: performing hanging detection on the process that handles the process keep-alive method through the interface provided by the hardware watchdog driver.

[0097] First, it should be noted that the process used for handling the process keep-alive method described in this embodiment is the same as the high-availability process described in the previous embodiments. In this embodiment, the keep-alive restart and hang-up of other processes are handled by the high-availability process, and the keep-alive restart of the high-availability process is handled by the process group. If the high-availability process hangs, the entire controller process failure cannot be handled. Therefore, hang detection of the high-availability process is performed through the interface provided by the hardware watchdog driver. If the high-availability process hangs, it will cause a watchdog timeout, and the controller will be killed and restarted by the watchdog.

[0098] As an optional implementation, the process of detecting hangs in a high-availability process through the interface provided by the hardware watchdog driver may include: (1) If the call to the interface provided by the hardware watchdog driver fails, no special handling is done, and the process is retried in the next round. (2) Check whether the pulse of the high-availability process is being pushed normally, that is, whether other threads such as the keep-alive thread and the logic thread of the high-availability process are normal. If they are normal, the high-availability process is detected for hangs through the interface provided by the hardware watchdog driver. If it is abnormally stalled, the high-availability process is restarted. (3) If the interface provided by the hardware watchdog driver itself is faulty, the entire controller is restarted.

[0099] In this embodiment, the process of the process keep-alive method can be hanged by the interface provided by the hardware watchdog driver, which ensures that the failure of the process keep-alive method is handled in a timely manner and avoids continuous interruption of the keep-alive process of the group joining process.

[0100] In some scenarios, to visually display the state transition information of the process under monitoring, this information can be recorded in a shared memory dashboard. In an exemplary embodiment, the method further includes recording the state transition information of the process under monitoring in a shared memory dashboard.

[0101] In this embodiment, each time the state of the process to be monitored changes, the high availability process writes the state information of the process to be monitored into a local memory dashboard maintained by the high availability process. The high availability process can read and write to this dashboard, while other modules can only read it. The information recorded on the memory dashboard is shown in Table 2 below.

[0102] Table 2

[0103] PROC_NAME Process name SESSION_ID (8 bytes) Composed of two parts: (1) high 32 bits for controller version number (2) low 32 bits for process identifier STATE(4 bytes) State of the process, OFF, Ready, Hung RESUME_CNT When the process is in OFF and Hung state, it will be executed by the high-availability process KILL and pull-up operation, each time +1

[0104] In this structure, the high 32 bits of SESSION_ID (process identifier) ​​represent the controller version number, which is taken from the operating system's running version number, ensuring monotonically increasing. The low 32 bits represent the process identifier (PID), ensuring a partial order within a certain period of the operating system's runtime lifecycle. SESSION_ID is updated after the process starts successfully, by calling the interface provided by the high-availability process (the interface takes the process type name and process PID as input parameters, and synthesizes SESSION_ID based on the controller version number and process identifier) ​​to update SESSION_ID and Ready in the Kanban board. The modifiers of the local process status Kanban board are the high-availability process and the corresponding process. The Off and Hung states are modified by the high-availability process, while the Ready state is written to the Kanban board after the corresponding process is ready. However, the transition of each state is driven by different events, so the timing of the changes is partial order. When the process status on the local dashboard changes, the high availability process publishes the global process status. When a process to be monitored enters the Off or Hung state, the process status in the memory dashboard is updated synchronously, and then the high availability process is notified. However, when a process is in the Ready state, the high availability process is notified only after the process status in the memory dashboard is confirmed to be Ready. When a process is in the Off or Hung state, the next step can be decided based on the process recovery count.

[0105] In this embodiment, the state transition information of the process to be monitored can be recorded and displayed through the shared memory dashboard. The state transition information of the process to be monitored is recorded in the shared memory dashboard, ensuring that the state data of the process to be monitored is always consistent with the keep-alive logic of the high availability module, thus avoiding the problem of incorrect execution of the keep-alive strategy due to misoperation of external modules.

[0106] The process keep-alive method proposed in this application will be explained and illustrated below through a complete embodiment. The process keep-alive method may include:

[0107] S1, if the monitoring process is confirmed to be started, determine the current state of the process to be monitored.

[0108] S2, if the preceding state is not ready and not in a zombie state, then perform a restart operation on the process to be monitored; if the preceding state is in a zombie state, then perform process hang detection on the process to be monitored, and perform a restart operation on the process to be monitored after the hang detection is completed.

[0109] The process of restarting the monitoring process includes:

[0110] The configuration file is read from shared memory; if it is not found in the shared memory, it is read from the hard drive. Based on the configuration file, the process to be monitored is restarted.

[0111] Perform process hang detection on the process to be monitored, including:

[0112] If the process to be monitored is a storage-side process or a protocol-side process, then the process hang detection is performed on the process to be monitored through a pulse clock mechanism based on scheduling round refresh.

[0113] If the process to be monitored is a management process, then a process hang detection is performed on the process to be monitored based on the heartbeat mechanism.

[0114] S3, after the process keep-alive operation of the process to be monitored is completed, if the new process group event received is a detection of the process to be monitored joining the group or a detection of the pulse push of the process to be monitored, then the subsequent state of the process to be monitored is determined to be ready; if the new process group event received is a detection of the process to be monitored leaving the group, then the subsequent state of the process to be monitored is determined to be not ready; if the new process group event received is a detection of the pulse stagnation of the process to be monitored, then the subsequent state of the process to be monitored is determined to be dead.

[0115] S4. If the preceding state of the process to be monitored is ready, and a group exit event of the process to be monitored is received, the following state of the process to be monitored is determined to be not ready; or, if a pulse stagnation of the process to be monitored is detected, the following state of the process to be monitored is determined to be dead.

[0116] S5 records the status transition information of the process to be monitored in the shared memory dashboard.

[0117] S6 uses the interface provided by the hardware watchdog driver to perform hang detection on the process of the process keep-alive method, ensuring that the failure of the process of the process keep-alive method is handled in a timely manner.

[0118] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps. It is understood that the steps in different embodiments can be freely combined as needed, and all non-contradictory solutions formed by such combinations are within the scope of protection of this application.

[0119] Based on the same inventive concept, this application also provides a process keep-alive device for implementing the process keep-alive method described above. The solution provided by this device is similar to the implementation described in the above method; therefore, the specific limitations in one or more process keep-alive device embodiments provided below can be found in the limitations of the process keep-alive method described above, and will not be repeated here.

[0120] In one exemplary embodiment, such as Figure 7 As shown, a process keep-alive device is provided, comprising: a first determining module, a keep-alive module, and a second determining module, wherein:

[0121] The first determination module is used to determine the current state of the process to be monitored when the monitoring process is determined to be started; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0122] The keep-alive module is used to perform corresponding process keep-alive operations on the process to be monitored if the previous state of the process to be monitored is a preset state.

[0123] The second determination module is used to determine the post-state of the process to be monitored based on the received new process group event and process state machine after the process keep-alive operation is completed.

[0124] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0125] In one embodiment, the preset state includes a not-ready and non-zombie state and a zombie state, and the keep-alive module includes: a first keep-alive unit and a second keep-alive unit, wherein:

[0126] The first keep-alive unit is used to perform a start-up operation on the process to be monitored if the previous state is not ready and not a zombie state.

[0127] The second keep-alive unit is used to perform process hang detection on the process to be monitored if the previous state is a zombie state, and to perform a restart operation on the process to be monitored after the hang detection is completed.

[0128] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0129] In one embodiment, the first keep-alive unit is configured to read the configuration file of the process to be monitored if the previous state is not ready, and perform a start-up operation on the process to be monitored based on the configuration file.

[0130] The aforementioned second keep-alive unit is used to perform process hang detection on the process to be monitored if the previous state is a zombie state, and after the hang detection is completed, read the configuration file of the process to be monitored and perform a restart operation on the process to be monitored based on the configuration file.

[0131] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0132] In one embodiment, the first keep-alive unit is configured to read the configuration file from the shared memory if the pre-state is not ready, and if the configuration file is not found in the shared content, then read the configuration file from the hard disk and perform a start-up operation on the process to be monitored based on the configuration file.

[0133] The aforementioned second keep-alive unit is used to perform process hang detection on the process to be monitored if the previous state is a zombie state, and read the configuration file from the shared memory after the hang detection is completed. If the configuration file is not read from the shared memory, the configuration file is read from the hard disk, and the process to be monitored is restarted based on the configuration file.

[0134] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0135] In one embodiment, the second keep-alive unit is configured to perform process hang detection on the process to be monitored by means of a pulse clock mechanism based on scheduling round refresh if the process to be monitored is a storage-side process or a protocol-side process; and to perform process hang detection on means of means of monitoring the process to be monitored by means of a heartbeat mechanism if the process to be monitored is a management-side process.

[0136] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0137] In one embodiment, the second determining module described above is configured to perform any one of the following operations:

[0138] If the new process group event is a detected entry event of the process to be monitored or a detected pulse push of the process to be monitored, then the post-state of the process to be monitored is determined to be ready.

[0139] If the new process group event is a detected event of the process to be monitored leaving the group, then the post-state of the process to be monitored is determined to be in an unready state.

[0140] If the new process group event detects a pause in the pulse of the process to be monitored, then the post-state of the process to be monitored is determined to be a zombie state.

[0141] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0142] In one embodiment, if the pre-state of the process to be monitored is a ready state, the above apparatus further includes: a third determining module, wherein:

[0143] The third determining module is used to determine the subsequent state of the process to be monitored as not ready if a leave event of the process to be monitored is received; or,

[0144] If the pulse of the process under monitoring is stopped, the subsequent state of the process under monitoring is determined to be a zombie state.

[0145] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0146] In one embodiment, the above apparatus further includes: a detection module, wherein:

[0147] The detection module is used to perform hang detection on processes using the keep-alive method through the interface provided by the hardware watchdog driver.

[0148] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0149] In one embodiment, the above apparatus further includes: a recording module, wherein:

[0150] The recording module is used to record the status transition information of the process to be monitored in a memory dashboard in shared memory.

[0151] The process keep-alive device provided in this embodiment can execute the above method embodiment, and its implementation principle and technical effect are similar, so it will not be described again here.

[0152] Each module in the aforementioned process keep-alive device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in the processor of a computer device in hardware form or independent of it, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0153] In one exemplary embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 8 As shown, this computer device includes a processor, memory, input / output (I / O) interfaces, and a communication interface. The processor, memory, and I / O interfaces are connected via a system bus, and the communication interface is also connected to the system bus via the I / O interfaces. The processor provides computational and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and a database. The internal memory provides the environment for the operating system and computer programs stored in the non-volatile storage media. The database stores the state transition information of processes under monitoring. The I / O interfaces are used for exchanging information between the processor and external devices. The communication interface is used for communicating with external terminals via a network connection. The computer program, when executed by the processor, implements a process keep-alive method.

[0154] Those skilled in the art will understand that Figure 8 The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0155] In one exemplary embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0156] Once it is confirmed that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0157] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation will be performed on the process to be monitored.

[0158] After performing the process keep-alive operation, the subsequent state of the process to be monitored is determined based on the received new process group event and process state machine.

[0159] In one embodiment, the preset state includes a not-ready and non-zombie state and a zombie state; when the processor executes the computer program, it also performs the following steps:

[0160] If the preceding state is not ready and not dead, then the process to be monitored will be restarted.

[0161] If the preceding state is a dead state, then a process hang detection is performed on the process to be monitored, and a restart operation is performed on the process to be monitored after the hang detection is completed.

[0162] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0163] Read the configuration file of the process to be monitored;

[0164] Based on the configuration file, a restart operation is performed on the process to be monitored.

[0165] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0166] The configuration file is read from shared memory, and if it is not found in the shared memory, it is read from the hard disk.

[0167] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0168] If the process to be monitored is a storage-side process or a protocol-side process, then the process hang detection is performed on the process to be monitored through a pulse clock mechanism based on scheduling round refresh.

[0169] If the process to be monitored is a management process, then a process hang detection is performed on the process to be monitored based on the heartbeat mechanism.

[0170] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0171] If the new process group event is a detected entry event of the process to be monitored or a detected pulse push of the process to be monitored, then the post-state of the process to be monitored is determined to be ready.

[0172] If the new process group event is a detected event of the process to be monitored leaving the group, then the post-state of the process to be monitored is determined to be in an unready state.

[0173] If the new process group event detects a pause in the pulse of the process to be monitored, then the post-state of the process to be monitored is determined to be a zombie state.

[0174] In one embodiment, if the pre-state of the process to be monitored is the ready state, the processor further performs the following steps when executing the computer program:

[0175] If a process leaving the group is received, the subsequent state of the process being monitored is determined to be in a non-ready state; or,

[0176] If the pulse of the process under monitoring is stopped, the subsequent state of the process under monitoring is determined to be a zombie state.

[0177] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0178] The hardware watchdog driver provides an interface to detect hangs in processes that are kept alive by the process management method.

[0179] In one embodiment, the processor, when executing a computer program, also performs the following steps:

[0180] Record the status transition information of the process to be monitored in the shared memory dashboard.

[0181] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0182] Once it is confirmed that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0183] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation will be performed on the process to be monitored.

[0184] After performing the process keep-alive operation, the subsequent state of the process to be monitored is determined based on the received new process group event and process state machine.

[0185] In one embodiment, the preset state includes a not-ready and non-zombie state and a zombie state; when the computer program is executed by the processor, it also performs the following steps:

[0186] If the preceding state is not ready and not dead, then the process to be monitored will be restarted.

[0187] If the preceding state is a dead state, then a process hang detection is performed on the process to be monitored, and a restart operation is performed on the process to be monitored after the hang detection is completed.

[0188] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0189] Read the configuration file of the process to be monitored;

[0190] Based on the configuration file, a restart operation is performed on the process to be monitored.

[0191] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0192] The configuration file is read from shared memory, and if it is not found in the shared memory, it is read from the hard disk.

[0193] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0194] If the process to be monitored is a storage-side process or a protocol-side process, then the process hang detection is performed on the process to be monitored through a pulse clock mechanism based on scheduling round refresh.

[0195] If the process to be monitored is a management process, then a process hang detection is performed on the process to be monitored based on the heartbeat mechanism.

[0196] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0197] If the new process group event is a detected entry event of the process to be monitored or a detected pulse push of the process to be monitored, then the post-state of the process to be monitored is determined to be ready.

[0198] If the new process group event is a detected event of the process to be monitored leaving the group, then the post-state of the process to be monitored is determined to be in an unready state.

[0199] If the new process group event detects a pause in the pulse of the process to be monitored, then the post-state of the process to be monitored is determined to be a zombie state.

[0200] In one embodiment, if the pre-state of the process to be monitored is the ready state, the computer program, when executed by the processor, further implements the following steps:

[0201] If a process leaving the group is received, the subsequent state of the process being monitored is determined to be in a non-ready state; or,

[0202] If the pulse of the process under monitoring is stopped, the subsequent state of the process under monitoring is determined to be a zombie state.

[0203] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0204] The hardware watchdog driver provides an interface to detect hangs in processes that are kept alive by the process management method.

[0205] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0206] Record the status transition information of the process to be monitored in the shared memory dashboard.

[0207] In one embodiment, a computer program product is provided, including a computer program that, when executed by a processor, performs the following steps:

[0208] Once it is confirmed that the monitoring process has started, the current state of the process to be monitored is determined; the process to be monitored is a process in the process group corresponding to the cluster system; the monitoring process is a process used to monitor the running status of the process to be monitored.

[0209] If the current state of the process to be monitored is a preset state, then the corresponding process keep-alive operation will be performed on the process to be monitored.

[0210] After performing the process keep-alive operation, the subsequent state of the process to be monitored is determined based on the received new process group event and process state machine.

[0211] In one embodiment, the preset state includes a not-ready and non-zombie state and a zombie state; when the computer program is executed by the processor, it also performs the following steps:

[0212] If the preceding state is not ready and not dead, then the process to be monitored will be restarted.

[0213] If the preceding state is a dead state, then a process hang detection is performed on the process to be monitored, and a restart operation is performed on the process to be monitored after the hang detection is completed.

[0214] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0215] Read the configuration file of the process to be monitored;

[0216] Based on the configuration file, a restart operation is performed on the process to be monitored.

[0217] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0218] The configuration file is read from shared memory, and if it is not found in the shared memory, it is read from the hard disk.

[0219] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0220] If the process to be monitored is a storage-side process or a protocol-side process, then the process hang detection is performed on the process to be monitored through a pulse clock mechanism based on scheduling round refresh.

[0221] If the process to be monitored is a management process, then a process hang detection is performed on the process to be monitored based on the heartbeat mechanism.

[0222] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0223] If the new process group event is a detected entry event of the process to be monitored or a detected pulse push of the process to be monitored, then the post-state of the process to be monitored is determined to be ready.

[0224] If the new process group event is a detected event of the process to be monitored leaving the group, then the post-state of the process to be monitored is determined to be in an unready state.

[0225] If the new process group event detects a pause in the pulse of the process to be monitored, then the post-state of the process to be monitored is determined to be a zombie state.

[0226] In one embodiment, if the pre-state of the process to be monitored is the ready state, the computer program, when executed by the processor, further implements the following steps:

[0227] If a process leaving the group is received, the subsequent state of the process being monitored is determined to be in a non-ready state; or,

[0228] If the pulse of the process under monitoring is stopped, the subsequent state of the process under monitoring is determined to be a zombie state.

[0229] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0230] The hardware watchdog driver provides an interface to detect hangs in processes that are kept alive by the process management method.

[0231] In one embodiment, when the computer program is executed by a processor, it also performs the following steps:

[0232] Record the status transition information of the process to be monitored in the shared memory dashboard.

[0233] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile memory and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory can include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM). The databases involved in the embodiments provided in this application may include at least one type of relational database and non-relational database. Non-relational databases may include, but are not limited to, blockchain-based distributed databases. The processors involved in the embodiments provided in this application may be general-purpose processors, central processing units, graphics processing units, digital signal processors, programmable logic devices, quantum computing-based data processing logic devices, artificial intelligence (AI) processors, etc., and are not limited to these.

[0234] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this application.

[0235] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of this patent application. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this application should be determined by the appended claims.

Claims

1. A process keep-alive method, characterized in that, The method comprises: In the case of determining the monitoring process to start, the pre-state of the process to be monitored is determined; the process to be monitored is a process in a process group corresponding to a cluster system; the monitoring process is a process for monitoring the running state of the process to be monitored; If the pre-state of the process to be monitored is a preset state, a corresponding process keep-alive operation is performed on the process to be monitored; After the process keep-alive operation is performed, the post-state of the process to be monitored is determined based on the received new process group event and process state machine.

2. The method of claim 1, wherein, The preset state includes an unready and non-stuck state and a stuck state; if the pre-state of the process to be monitored is a preset state, a corresponding process keep-alive operation is performed on the process to be monitored, which comprises: If the pre-state is the unready and non-stuck state, a pull-up operation is performed on the process to be monitored; If the pre-state is the stuck state, process hanging detection is performed on the process to be monitored, and after the hanging detection is completed, a pull-up operation is performed on the process to be monitored.

3. The method of claim 2, wherein, The pull-up operation performed on the process to be monitored comprises: Reading the configuration file of the process to be monitored; Based on the configuration file, a pull-up operation is performed on the process to be monitored.

4. The method of claim 3, wherein, The reading of the configuration file of the process to be monitored comprises: The configuration file is read from the shared memory, and if the configuration file is not read from the shared content, the configuration file is read from the hard disk.

5. The method of claim 2, wherein, The process hanging detection performed on the process to be monitored comprises: If the process to be monitored is a storage-side process or a protocol-side process, the process hanging detection is performed on the process to be monitored through a pulse clock mechanism based on a scheduling round refresh; If the process to be monitored is a management-side process, the process hanging detection is performed on the process to be monitored based on a heartbeat mechanism.

6. The method of claim 1, wherein, The determination of the post-state of the process to be monitored based on the received new process group event and process state machine comprises any one of the following: If the new process group event is a process group detection event of the process to be monitored or a pulse push detection event of the process to be monitored, it is determined that the post-state of the process to be monitored is a ready state; If the new process group event is a process group exit event of the process to be monitored, it is determined that the post-state of the process to be monitored is an unready state; If the new process group event is a pulse stagnation detection event of the process to be monitored, it is determined that the post-state of the process to be monitored is a stuck state.

7. The method of claim 1, wherein, If the pre-state of the process to be monitored is a ready state, the method further comprises: If the process group exit event of the process to be monitored is received, it is determined that the post-state of the process to be monitored is an unready state; or, If the pulse stagnation of the process to be monitored is detected, it is determined that the post-state of the process to be monitored is a stuck state.

8. The method of claim 1, wherein, The method further comprises: Through an interface provided by a hardware watchdog driver, a process for processing the process keep-alive method is hung up for detection.

9. The method of claim 1, wherein, The method further comprises: State transition information of the process to be monitored is recorded in a memory board of shared memory.

10. A process keep-alive apparatus, characterized by comprising: The device comprises: A first determining module is configured to determine a pre-state of a to-be-monitored process in a case where it is determined that a monitoring process is started; the to-be-monitored process is a process in a process group corresponding to a cluster system; and the monitoring process is a process configured to monitor a running state of the to-be-monitored process. A keep-alive module is configured to perform a corresponding process keep-alive operation on the to-be-monitored process in a case where the pre-state of the to-be-monitored process is a preset state. A second determining module is configured to determine a post-state of the to-be-monitored process based on a received new process group event and a process state machine after the process keep-alive operation is performed. 11.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-10 when the computer program is executed by the processor. The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 9.

12. A computer readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 9.

13. A computer program product comprising a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 9.

Images