Process management method and computing device

Abstract

The embodiment of the present application provides a process management method, including: obtaining a signal to be processed of a process in an operating system kernel; obtaining associated information of the signal to be processed when the signal to be processed matches a preset monitoring signal; wherein the associated information includes process call information and user information related to the signal to be processed; and recording the associated information of the signal to be processed into a log file of the operating system. The signal information of the process is recorded in the log file of the Linux system, so that the operation and maintenance personnel can quickly trace the signal of the process by querying the operating system log file.

Description

Technical Field

[0001] The present application relates to the field of server technology, and in particular to a process management method and computing device. Background Art

[0002] The Linux operating system is an operating system developed based on the Unix operating system. In the Linux operating system, multiple users are allowed to use computer resources at the same time, and multiple tasks can be run in parallel. As a multi-user system, Linux provides a safe and reliable user authentication and permission management mechanism, and each user can have his own account and independent user environment. During the development and debugging of Linux, multiple developers can log in with the same user account and carry out system development and maintenance. At this time, the developer will face a problem. The process in the background of the system is closed, but it is unknown who issued the instruction. In Linux, the logs of process operation are not recorded. Therefore, when the developer queries all the log records in the Linux system, no relevant log records can be found. Summary of the invention

[0003] The embodiments of the present application provide a process management method and a computing device, which can record the signal information of the process into the log file of the Linux operating system, so that operation and maintenance personnel can quickly trace the process signal and locate the problem by querying the operating system log file.

[0004] In a first aspect, an embodiment of the present application provides a process management method, which is applied to a computing device, in which an operating system is configured. The method includes: obtaining a signal to be processed of a process in a kernel of the operating system; when the signal to be processed matches a preset monitoring signal, obtaining associated information of the signal to be processed; wherein the associated information includes process call information and user information related to the signal to be processed; and recording the associated information of the signal to be processed in a log file of the operating system.

[0005] In this solution, a pending signal of a process in the operating system kernel is obtained. If the pending signal is a signal in a preset monitoring signal list, the pending signal is analyzed to obtain related information of the pending signal. Then, the related information of the pending signal is recorded in the log file of the operating system, so that the operation and maintenance personnel can obtain the relevant data information of the pending signal in the sending process by querying the operating system log file, thereby realizing the rapid tracing of the pending signal.

[0006] In a possible implementation, the method further includes: when the signal to be processed belongs to a signal in the monitoring signal list, determining whether the signal to be processed belongs to a truncated signal; wherein the truncated signal is a signal to abandon execution; when the signal to be processed belongs to a truncated signal, truncating the signal to be processed.

[0007] In this solution, after determining that the signal to be processed belongs to a signal in the monitoring signal list, it is also necessary to determine whether the signal to be processed is a truncated signal. In the case where it is determined that the signal to be processed belongs to a truncated signal, the signal to be processed is truncated. By truncating unexpected signals of key processes of the system, the stability of the operating system is guaranteed and the serviceability of the business in the server is improved. Among them, "truncated signal" may refer to a signal that needs to be abandoned. For truncated signals, after the truncated signal enters the operating system kernel, the signal needs to be captured and discarded, and the truncated signal is prohibited from being stored in the signal queue of the corresponding process.

[0008] In one possible implementation, the process call information includes a target process that receives a signal to be processed; when the signal to be processed belongs to a signal in a monitoring signal list, determining whether the signal to be processed belongs to a truncated signal, including: determining whether the target process matches a process in a preset key process list; when there is a first process in the key process list that matches the target process, determining whether the signal to be processed matches a signal corresponding to the first process; when there is a first signal in the signals corresponding to the first process that matches the signal to be processed, obtaining a processing strategy corresponding to the first signal; and determining whether the signal to be processed is a truncated signal according to the processing strategy corresponding to the first signal.

[0009] In this solution, a policy configuration file is saved in advance in the operating system, and the policy configuration file includes a list of key processes, signals corresponding to the key processes, and processing strategies corresponding to the signals. When determining whether a signal to be processed is a truncated signal, it is first necessary to determine whether the target process receiving the signal to be processed is a key process. After determining that the target process receiving the signal to be processed is a process in the key process list, it is also necessary to determine whether the signal to be processed is a signal corresponding to the key process. After determining that the signal to be processed is a signal corresponding to the key process, it can be determined whether the signal to be processed is a truncated signal based on the processing strategy of the signal corresponding to the key process.

[0010] In a possible implementation, the method further includes: when the signal to be processed is not a truncated signal, the operating system kernel executes the signal to be processed.

[0011] In this solution, when the signal to be processed is not a truncated signal, no other operation is required for the signal to be processed, that is, the execution of the signal to be processed is not affected.

[0012] In a possible implementation, when the signal to be processed does not belong to a truncated signal, the method also includes: determining whether the signal to be processed belongs to a preset alarm signal; when the signal to be processed belongs to the preset alarm signal, generating alarm information according to the associated information of the signal to be processed; and reporting the alarm information.

[0013] In this solution, when the pending signal does not belong to the truncated signal, the pending signal will be placed in the signal queue of the target process that receives the pending signal and executed. For pending signals that belong to the monitoring signal list but do not belong to the truncated signal, it can be determined whether the pending signal belongs to the signal in the alarm signal list. If the pending signal belongs to the signal in the alarm signal list, it is also necessary to generate alarm information of the pending signal based on the associated information of the pending signal and report the alarm. By alarming specific signals, the timeliness of the operating system's exception handling can be improved.

[0014] In a possible implementation, reporting the alarm information includes: determining the alarm number of the signal to be processed; and reporting the alarm information when the alarm number is less than a first threshold.

[0015] In this solution, when an alarm is issued for a signal to be processed, the number of alarms of the signal to be processed is compared with a preset first threshold, and an alarm is issued only when the number of alarms of the signal to be processed is less than the first threshold, thereby avoiding frequent alarms for the same signal in a short period of time.

[0016] In a possible implementation, the method further includes: when the number of alarms is greater than or equal to a first threshold, suppressing reporting of alarm information, and recording the number of times the alarm of the signal to be processed is suppressed.

[0017] In this solution, when the number of alarms is greater than the first threshold, it indicates that the alarms for the signal to be processed are too frequent, and it is necessary to suppress the alarms for the signal to be processed.

[0018] In a possible implementation, obtaining a signal to be processed of a process in an operating system kernel includes: obtaining the signal to be processed in the operating system kernel by extending a Berkeley packet filter eBPF.

[0019] In this solution, the eBPF mechanism can be used to capture and analyze the signals to be processed in the kernel. Since the eBPF mechanism can inject the written code into the kernel to add some functions to the kernel without modifying the kernel code itself, loose coupling with the kernel is achieved.

[0020] In a possible implementation, the process calling information related to the signal to be processed includes: one or more of: a source process sending the signal, a calling path of the signal, and a target process receiving the signal.

[0021] In this solution, when obtaining process call information related to the signal to be processed, the source process that sends the signal and the target process that receives the signal can be directly obtained from the information carried by the signal to be processed. The call path of the signal can be obtained by analyzing the source process that sends the signal.

[0022] In a second aspect, an embodiment of the present application provides an operating system, including:

[0023] A signal capture module, used to obtain a signal to be processed of a process in the operating system kernel, and when the signal to be processed matches a preset monitoring signal, obtain associated information of the signal to be processed; wherein the associated information includes process call information and user information related to the signal to be processed; and record the associated information of the signal to be processed into a log file of the operating system;

[0024] The signal analysis module is used to determine whether the signal to be processed is a truncated signal when the signal to be processed belongs to a signal in the first signal list monitoring signal list; wherein the truncated signal is a signal to abandon execution; when the signal to be processed belongs to the truncated signal, the signal to be processed is truncated. ;

[0025] The alarm reporting module is used to determine whether the signal to be processed belongs to the preset alarm signal when the signal to be processed does not belong to the truncated signal; if the signal to be processed belongs to the preset alarm signal, generate alarm information according to the associated information of the signal to be processed; and report the alarm information.

[0026] In a third aspect, an embodiment of the present application provides a computing device, the computing device comprising: a memory and a processor; the memory and the processor are coupled;

[0027] The memory is used to store program instructions;

[0028] A processor is used to execute program instructions stored in a memory; when the program instructions are executed, the processor is used to execute the method described in the first aspect or any possible implementation manner of the first aspect.

[0029] In a fourth aspect, an embodiment of the present application provides a computer storage medium, in which instructions are stored. When the instructions are executed on a computer, the computer executes the method described in the first aspect or any possible implementation of the first aspect.

[0030] In a fifth aspect, an embodiment of the present application provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to execute the method described in the first aspect or any possible implementation of the first aspect. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0032] Figure 1 A schematic diagram of the system architecture of an Audit subsystem provided in an embodiment of the present application;

[0033] Figure 2 A schematic diagram of a coredump workflow provided in an embodiment of the present application;

[0034] Figure 3 A schematic diagram of the internal structure of a computing device provided in an embodiment of the present application;

[0035] Figure 4 A schematic diagram of the architecture of a computing device provided in an embodiment of the present application;

[0036] Figure 5 A schematic diagram of the structure of an operation and maintenance module provided in an embodiment of the present application;

[0037] Figure 6 A flowchart of a process management method provided in an embodiment of the present application;

[0038] Figure 7 A flowchart of a process management method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0039] In order to make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0040] In the description of the embodiments of the present application, any embodiment or design scheme of "exemplary", "for example" or "for example" should not be understood as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary", "for example" or "for example" is intended to present related concepts in a specific way.

[0041] In addition, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include one or more of the features. The terms "include", "comprises", "has" and their variations all mean "including but not limited to", unless otherwise specifically emphasized.

[0042] For processes in Linux systems, developers and operation and maintenance engineers urgently need a method or log to locate and trace abnormally closed processes to ensure that they can respond to abnormally closed processes in a timely manner to prevent key business from being damaged. For example, process signals can be tracked through the Audit system in the Linux system. The Audit subsystem is a functional module in the Linux kernel that aims to provide security auditing and event logging functions. It can record various important events that occur in the system, including process creation, file access, system calls, etc. Among them, tracking kernel signals is one of the main functions of Audit. The Audit subsystem communicates with the kernel through system calls and kernel modules. When the Audit service is configured with signal rules and started, the kernel will trigger the Audit subsystem when it receives the corresponding signal. For example, Figure 1 A schematic diagram of the system architecture of the Audit subsystem is shown in FIG. Figure 1 As shown, it includes: a kernel module, a rule configuration module, a command line interface, a daemon process (Audit), a daemon process configuration module and a log module. Among them, the kernel module includes: an Audit filtering rule processor.

[0043] Audit is a module in the kernel, and the operation of the kernel will be recorded in Audit. Specifically, the super user can configure the Audit rule file through the rule configuration module, and write the Audit rule file into the Audit filter rule processor in the kernel module through the command line interface. During the running of the application, the operations on the application include: user events, process creation, system calls, etc. These operations will be captured and filtered by the Audit filter rule processor in the kernel module. The filtered data will be transmitted to the daemon process, and then operated by the daemon process. For example, the filtered data is saved in the log module. The daemon configuration module stores the configuration file of the daemon process. The configuration file can be used to determine how the daemon process is started and where the log file is stored. Operation and maintenance engineers can use the ausearch tool to query the recorded logs to obtain relevant information about the process. Although the Audit subsystem can record process information, there are still the following problems:

[0044] After Audit captures the process information of the current signal sender, it can only trace the source one level upward. If the sender (the process that sends the signal) is called by multiple other processes, it is impossible to determine the most direct call chain of the signal, causing the process information recorded by Audit to lack call chain information. Secondly, the Audit subsystem cannot intercept signals, and the sender information of the signal recorded by the Audit subsystem can only be used as evidence for post-location. When the Audit subsystem obtains critical signals, the critical signals will still be processed, which may cause critical service anomalies in the system. After the critical signals are processed, the Audit subsystem cannot report alarms, resulting in the system administrator being unable to monitor and process related processes.

[0045] Coredump (core dump) can also record process information. Coredump is a mechanism in the operating system that saves the memory image of a process as a file. When a serious error occurs in a program, causing it to crash or terminate abnormally, coredump will record the state and operating environment of the program at the time of the crash, including stack information, register status, memory image, etc. Coredump files can be used by developers to debug and analyze the cause of program failures.

[0046] The operating system provides command line parameters to set coredump. By default, this function is disabled and needs to be enabled by the user through a service or script before starting the process. Figure 2 See Figure 2 , the kernel scheduler can schedule processes in the runnable process queue. When scheduling a process, if the process has a signal to be processed, the kernel scheduler will give priority to the process with the signal to be processed. For example, if process A in the runnable process queue has a signal to be processed, the kernel scheduler can give priority to process A. After selecting process A, it determines whether a coredump file needs to be generated based on the mark of the signal processed by process A. For example, if a coredump file needs to be generated, process A exits after the coredump file is generated, otherwise process A exits directly. For the generated coredump file, the operation and maintenance personnel can use gdb and the process binary debugging file to open the coredump file and analyze the reason for the process exit.

[0047] Although coredump can record the status and running environment of the program when it crashes or terminates abnormally due to a serious error. However, not all processes will generate coredump files when they exit. Only when the program is in elf file format, a coredump file will be generated when the process of the program exits. If the program is not in elf file format, a coredump file cannot be generated when the process of the program exits. Secondly, there are many kinds of signals that cause the process to exit, and only a few signals can generate coredump files. Finally, coredump cannot intervene in the exit of the process. After the process receives the exit signal, it immediately processes the signal and exits the process. If the key in the system is killed by mistake, it is difficult to trace the perpetrator. If it cannot be stopped in time, the situation of killing the process by mistake may occur again.

[0048] Although the above-mentioned Audit subsystem and coredump can record process information, the existing process exit tracking method has the problem of being unable to trace the source of the signal. For example, after the key process of the subsystem is closed, the obtained log information is insufficient to support the rapid delimitation and positioning of the process exit. In addition, the existing process exit tracking method cannot further process the key signal event after capturing the key signal to improve the reliability of the key process of the system.

[0049] In view of this, an embodiment of the present application provides a process management method, when a process in a Linux system sends a signal and enters the kernel through a system call, the signal is obtained from the kernel, and the information of the obtained signal is recorded in the log file of the operating system, and the obtained signal is analyzed. When the obtained signal belongs to a signal that needs to be truncated, the obtained signal is truncated to shield the impact on the key process of the system. In the process of analyzing the obtained signal, when the obtained signal belongs to a signal in the alarm list, it is also necessary to alarm the obtained signal so that the management personnel can process the signal in advance and improve the reliability of the key process of the system.

[0050] It is understandable that in the embodiment of the present application, "truncated signal" may refer to a signal that needs to be abandoned. For a truncated signal, after the truncated signal enters the operating system kernel, the signal needs to be captured and discarded, that is, the truncated signal cannot be stored in the signal queue of the corresponding process.

[0051] For example, Figure 3 FIG. 1 is a schematic diagram showing the internal structure of a computing device according to an embodiment of the present application. Figure 3As shown, the computing device may include a power supply 121 and a motherboard 110. The power supply 121 is electrically connected to the motherboard 110 and is used to supply power to the devices on the motherboard 110. The motherboard 110 includes a central processing unit (CPU) 111, a memory 112, a programmable logic device (PLD) 113, a baseboard management controller (BMC) 114, a PCIe slot 115, a network card 122, a hard disk 123, and a fan 124.

[0052] Among them, the memory 112 is inserted into the memory slot, which is used as an external cache. Exemplarily, the memory 112 can be a random access memory (RAM). By way of example but not limitation, many forms of RAM are available, such as static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous connection dynamic random access memory (SLDRAM) and direct memory bus random access memory (DRRAM).

[0053] The PCIe slot 115 is suitable for expanding at least one of a graphics processing unit (GPU) card, a network card, a video capture card, an HBA (Host Bus Adapter) card, a RAID (redundant arrays of independent disks) card, and an SSD (solid state disk or solid state drive), and can also support the expansion of various adapter cards.

[0054] The programmable logic device 113 may be a complex logic device (CPLD, which is a digital integrated circuit whose logic functions are constructed by users according to their own needs) or a field programmable gate array (FPGA).

[0055] The BMC 114 has a BMC interface.

[0056] Hard disk 123 is classified according to the protocol used by the interface, including SAS (serial attached SCSI), SATA (serial advanced technology attachment), and NVMe (non-volatile memory express) hard disks. It is classified according to the hard disk medium, including mechanical hard disk drive (HDD) and solid state drive (Solid State Disk or Solid State Drive, SSD). Among them, HDD often uses SATA and SAS interfaces. SSD solid state hard disk consists of a control unit and a storage unit (FLASH chip, DRAM chip), and can use SATA, SAS, PCIe interface and M.2 interface. Among them, the M.2 interface mainly uses the NVMe interface protocol.

[0057] For example, Figure 4 A schematic diagram of a specific architecture of a computing device provided in an embodiment of the present application is shown. Figure 4 As shown, the computing device can be divided into: hardware layer, kernel layer and application layer from bottom to top.

[0058] Exemplarily, the operating system installed on the computing device is a Linux system.

[0059] The hardware layer is used to provide the underlying hardware support for the Linux system. The hardware deployed in the hardware layer may include: CPU, memory, hard disk, network card, etc.

[0060] The kernel layer is the core and foundation of the Linux system. It runs directly on the hardware platform, controls and manages various resources within the system (including hardware resources and software resources), and effectively organizes the running of processes, thereby expanding the functions of the hardware and improving resource utilization efficiency.

[0061] like Figure 4 As shown, the kernel layer can be responsible for the following functions: process scheduling, signal processing and network management. The kernel layer also includes the signal capture module and signal analysis module in the operation and maintenance module.

[0062] The application layer can implement corresponding functions by calling functions, such as opening files, closing files, reading / writing files, etc. Figure 4 As shown, the application layer may include: business APP, log management, alarm platform, alarm reporting module in the operation and maintenance module, etc.

[0063] The operation and maintenance module includes: signal capture module, signal analysis module and alarm reporting module. The operation and maintenance module can serve as an intermediate link between the kernel and the application. The signal capture module and signal analysis module in the operation and maintenance module are deployed in the kernel layer, so that the operation and maintenance module can connect to the kernel in the south. The alarm reporting module in the operation and maintenance module is deployed in the application layer, so that the operation and maintenance module can communicate with third-party applications in the application layer (for example, business APP, log management, and alarm platform) in the north. The operation and maintenance module can act on the signal processing flow of the kernel through the extended Berkeley packet filter (eBPF) mechanism. When the signal sent by the process enters the kernel through the system call, the signal entering the kernel is called back to the operation and maintenance module for signal capture, signal analysis, and alarm reporting.

[0064] It is understandable that eBPF means "extensible packet filter" and is a filtering technology for network packets. As an extended version of BPF, eBPF supports the JIT mechanism, dynamically interprets user-defined instructions into machine code, and executes them in the kernel, which greatly improves flexibility. Before eBPF, kernel modules were the main mechanism for injecting into the kernel. Due to the lack of security control over kernel modules, the basic functions of the kernel can be easily destroyed by a defective kernel module. eBPF uses the Just-in-Time Compiler (JIT) and pre-controls the open implantation range and verification program in the kernel to ensure that only verified safe eBPF instructions will be executed by the kernel.

[0065] In a possible example, the structural diagram of the operation and maintenance module can be as follows: Figure 4 See Figure 4 ,The operation and maintenance module includes : signal capture module, signal analysis module and alarm reporting module.

[0066] The signal capture module is responsible for tracking and processing signals in the operating system, including: obtaining signal association information. The association information may include process call information and user information related to the signal. The process call information related to the signal includes information such as the source process that sends the signal, the call path of the signal, and the target process that receives the signal, and the collected signal association information is recorded in the log of the operating system. The signal capture module can track the processing function of sending the signal through the eBPF mechanism. A complete eBPF program usually consists of two parts: user state and kernel state: the user state program needs to interact with the kernel through the BPF system call to complete tasks such as eBPF program loading, event mounting, and mapping creation and update; in the kernel state, the eBPF program cannot call kernel functions arbitrarily, but needs to complete the required tasks through the BPF auxiliary function. Especially when accessing memory addresses, it is necessary to use the bpf_probe_read series of functions to read memory data to ensure safe and efficient memory access.

[0067] In user mode: Users can write eBPF programs directly in eBPF assembly or C language. The operating system calls the LLVM / Clang compiler to compile the eBPF program into eBPF bytecode. The compiled eBPF bytecode will be loaded by the high-level language program corresponding to eBPF, and the high-level language will perform system call processing. For example, the eBPF bytecode is loaded into the Linux system kernel by calling the bpf() system call to complete component initialization. Specifically, the pre-compiled eBPF kernel-mode component is mounted in the Linux system on the function that needs to be called to send the signal.

[0068] In kernel state: After the eBPF bytecode falls into the kernel through a system call, it is first verified by the kernel eBPF program. Verification by the eBPF program can confirm that the program itself is correct (no crash, no dead loop), and there are no permission exceptions. Then, the program compiled into eBPF pseudocode is converted into a specific machine instruction set to optimize program execution, and finally mounted to the corresponding hook point or tracking point. When the kernel is processing a tracking point, if an eBPF instruction happens to be mounted, an event will be triggered and processed by the loaded eBPF program.

[0069] It is understood that eBPF programs are event-driven and are triggered when the kernel or application passes a hook point. Predefined hooks include: system calls, function entry / exit, kernel tracepoints, network events, etc. If there is no predefined hook for a specific need, you can create a kernel probe (kprobe) or user probe (uprobe) to attach the eBPF program to almost anywhere in the kernel or user application.

[0070] In a possible example, the signal capture module may include: a signal configuration module, an information acquisition module, and a log recording module.

[0071] The signal configuration module can provide a configuration interface for the system administrator or other processes. The administrator and other programs can modify the configuration file of the signal capture module through the configuration interface provided by the signal configuration module. Among them, a monitoring signal list is set in the configuration file of the capture module. When the capture module is performing signal capture, the signal in the monitoring signal list can be captured. For example, the signals SIGQUIT and SIGKILL that need to be paid attention to can be configured in the monitoring signal list of the configuration file.

[0072] In a possible example, the administrator and other programs can modify the monitoring signal list in the configuration file through the configuration interface provided by the signal configuration module to set the signals that need attention. The monitoring signal list can be as shown in Table 1.

[0073] Table 1

[0074] Pay attention to signal identification Signal value SIGQUIT 9 SIGKILL 15

[0075] It is understandable that a default signal is set in the monitoring signal list, and the system administrator or process can modify, add or delete the signal in the monitoring signal list through the configuration interface provided by the signal configuration module. If the system administrator or process does not configure the monitoring signal list, the monitoring signal list will maintain the default configuration, that is, retain the default configuration information.

[0076] The information acquisition module can analyze the information carried by the signal captured from the kernel during transmission to obtain the associated information of the captured signal. For example, the information acquisition module can obtain the source process of the signal, the call path of the signal, the target process of the signal, and the user information by analyzing the information carried during the signal transmission. Among them, the source process of the signal and the target process of the signal can be directly obtained from the information carried by the captured signal, and the call path and user information of the sender can be obtained by analyzing the source process of the signal. For example, the parent process of the source process is obtained through the parent process identification (PPID) in the source process, and the parent process of the parent process of the source process is obtained by analyzing the parent process of the source process. When obtaining the user information of the signal, there is a corresponding user information for each parent process in the signal call path. Therefore, when analyzing the user information of the signal, at least one user information can be obtained.

[0077] After acquiring the information carried by the signal, the information acquisition module may send the acquired signal identifier and the information carried by the signal to the log recording module.

[0078] After the log recording module receives the signal sent by the information acquisition module and the information carried by the signal, it needs to record the signal and its corresponding information together in the operating system log.

[0079] The signal analysis module is used to further process the signal captured by the signal capture module according to a preset processing strategy. For example, the target signal is cut off to prevent the kernel from continuing to process. Specifically, the strategy analysis module may include: a strategy configuration module and a strategy execution module.

[0080] The policy configuration module is used to provide a configuration interface for system administrators or other processes. Administrators or programs can directly modify the policy configuration file through the configuration interface to configure the signal processing process of key processes. For example, a key process list can be generated in the configuration file, and the processing strategy of the shutdown signal of the process in the key process list can be configured.

[0081] In a possible example, the configuration file may be as shown in Table 2.

[0082] Table 2

[0083] Key process identifier Signal value Treatment strategy Process 1 9 (Exit signal) Cut off the signal Process 2 7 (suspend signal) Execute the signal Process 3 9 (Exit signal) Execute the signal

[0084] It is understandable that the configuration files in Table 2 are pre-set with default values. The system administrator or process can modify, add or delete the key process through the configuration interface provided by the signal configuration module. If the system administrator or process does not configure the key process, the default configuration is maintained for the key process and the signal value and processing strategy corresponding to the key process in the configuration file, that is, the default configuration information is retained.

[0085] The policy execution module is used to process the signals of the key processes according to the policy configuration of the key processes in the policy configuration file. For example, the policy configuration of the "exit signal" of the key process A in the policy configuration file is "intercept the exit signal". After obtaining the "exit signal" of process A, the policy execution module obtains the context of the "exit signal" of process A and records the obtained context in the system log. Then, the sending process of the "exit signal" of process A is skipped.

[0086] The alarm reporting module is used to package the information of the signal that needs to be alarmed into a data packet and push it to the alarm platform when the signal captured by the signal capture module belongs to the signal that needs to be alarmed. Specifically, the alarm reporting module includes: an alarm management module, a data arrangement module, and an alarm push module.

[0087] The alarm management module is used to provide a configuration interface for system administrators or other processes. Administrators or programs can directly modify configuration files through the configuration interface to set alarm signals, alarm interfaces, and alarm frequencies.

[0088] In a possible example, the configuration file in the alarm reporting module may be as shown in Table 3.

[0089] Table 3

[0090] Warning signal identification Signal value Alarm reporting interface SIGQUIT 9 NULL SIGKILL 15 NULL

[0091] It is understandable that the configuration file in Table 3 is pre-set with default values. The system administrator or process can modify, add or delete the signal that needs to be alarmed through the configuration interface provided by the signal configuration module. If the system administrator or process does not set the signal that needs to be alarmed, the default configuration is maintained for the signal that needs to be alarmed and the signal value corresponding to the signal that needs to be alarmed and the alarm reporting interface in the configuration file, that is, the default configuration information is retained.

[0092] The data arrangement module is used to generate alarm information according to the information of the received signal when the received signal belongs to the signal in the alarm list in the configuration file. Then, the data arrangement module organizes the generated alarm information into an alarm message, adds an alarm code, and passes it to the alarm push module to complete the alarm.

[0093] After receiving the alarm message sent by the data orchestration module, the alarm push module checks whether the alarm frequency of the alarm signal carried in the alarm message reaches the preset alarm threshold. If the alarm frequency of the signal that needs to be alarmed exceeds the alarm threshold, the alarm push module needs to stop alarming the signal and record the number of times the signal is suppressed. If the alarm frequency of the signal that needs to be alarmed does not exceed the alarm threshold, the alarm push module can call the alarm reporting interface to send the alarm message to the alarm platform and record the alarm frequency of the signal. Among them, the alarm push module can send the alarm information to a third-party platform. For example, the alarm information can be recorded in the local database of the server, and the alarm data can be pushed to the management platform through the background process of the server, or the administrator can be notified by sending emails, etc., so as to improve the timeliness of the operation and maintenance personnel in processing the alarm signal and improve the reliability of the operating system.

[0094] In a possible example, the configuration files in the signal capture module, the signal analysis module, and the alarm reporting module may be implemented by one configuration file. Specifically, it may be as shown in Table 4.

[0095] Table 4

[0096] Configuration items Signal Identification Key process identifier Signal value Alarm reporting interface Treatment strategy Monitoring signal list SIGQUIT / 9 / / SIGKILL / 15 / / Critical process list / Process 1 9 (Exit signal) / Cut off the signal / Process 2 7 (suspend signal) / Execute the signal / Process 3 9 (Exit signal) / Execute the signal Warning signal list SIGQUIT / 9 NULL / SIGKILL / 15 NULL /

[0097] The system administrator or other processes can modify the corresponding configuration items in the configuration file shown in Table 4 through the configuration interface provided by the signal capture module, the signal analysis module and the alarm reporting module. For example, the system administrator or other processes can configure each table item (e.g., signal identifier, signal value) in the monitoring signal list through the signal configuration module in the signal capture module. The system administrator or other processes can configure each table item (e.g., key process identifier, signal value, processing strategy) in the key process list through the policy configuration module in the signal analysis module. The system administrator or other processes can configure each table item (e.g., signal identifier, signal value, alarm reporting interface) in the alarm signal list through the alarm management module in the alarm reporting module.

[0098] In a possible example, when the configuration files in the signal capture module, the signal analysis module, and the alarm reporting module are set, the operating system may provide a corresponding graphical interface to lower the user's usage threshold.

[0099] In an embodiment of the present application, by adding a signal capture module, a signal analysis module and an alarm reporting module, the signal in the kernel can be captured by the signal capture module, and the information of the captured signal is recorded in the system log, so that the subsequent operation and maintenance personnel can trace the source of the signal according to the information recorded in the system log. The unexpected signals of the key process can be shielded by the signal analysis module to ensure that the key business process is not unexpectedly closed. Finally, through the alarm module, the specific signals executed by the kernel are alarmed to improve the timeliness of the system exception handling. And the functions of the signal capture module and the signal analysis module are implemented in the kernel through the eBPF mechanism, realizing the loose coupling of the signal capture module and the signal analysis module with the kernel.

[0100] Next, based on the above description, a process management method provided by an embodiment of the present application is introduced. The method can be applied to Figure 4 The computing device shown. Exemplary, Figure 6 A flowchart of a process management method provided by an embodiment of the present application is shown. Figure 6 The method includes: step 601-step 603.

[0101] Step 601, obtaining a signal to be processed in the operating system kernel.

[0102] In this embodiment, the signal processing flow in the memory can be tracked through the eBPF mechanism to obtain all pending signals processed in the kernel.

[0103] In a possible example, a precompiled eBPF kernel state component is mounted on the function of the kernel signal sending process. When the process sends a signal and enters the kernel through a system call, the signal entering the kernel can be captured through eBPF.

[0104] Step 602: When the signal to be processed is a signal in the monitoring signal list, the signal to be processed is analyzed to obtain associated information of the signal to be processed.

[0105] In this embodiment, after the signal to be processed is captured from the kernel, it is necessary to determine whether the captured signal to be processed belongs to a signal in the monitoring signal list. The monitoring signal list can be set in advance, for example, the system administrator or other processes configure the signal in the monitoring signal list through the configuration interface provided by the signal configuration module in the signal capture module.

[0106] In a possible example, the monitoring signal list may be as shown in Table 1 in the above embodiment. When determining whether the acquired signal to be processed belongs to a signal in the monitoring signal list, the identifier of the captured signal to be processed may be matched with the signal identifier in the monitoring signal list. If there is a signal identifier in the monitoring signal list that matches the identifier of the acquired signal to be processed, it is determined that the acquired signal to be processed belongs to a signal in the monitoring signal list.

[0107] After the captured signal to be processed belongs to the monitoring signal list, it is necessary to analyze the signal to be processed and obtain the associated information of the signal to be processed. Among them, the associated information of the signal to be processed includes process call information and user information related to the signal to be processed. The process call information related to the signal to be processed includes: the source process that sends the signal, the call path of the signal, the target process that receives the signal, etc. Among them, the source process that sends the signal and the target process that receives the signal can be obtained by analyzing the signal to be processed. After obtaining the source process that sends the signal, the user information and the parent process of the source process that sends the signal can be obtained by analyzing the source process that sends the signal. By analyzing the parent process of the source process that sends the signal, the parent process of the parent process can be obtained, and the call path of the signal sender can be obtained by recursive analysis.

[0108] Step 603: Record the associated information of the signal to be processed into a log file of the operating system.

[0109] In this embodiment, after the associated information of the signal to be processed is obtained, it is also necessary to record the acquired associated information of the signal to be processed into the system log of the operating system to facilitate the operation and maintenance personnel to quickly trace the execution signal.

[0110] In one possible example, after determining that the acquired signal to be processed belongs to a signal in the monitoring signal list, it is also necessary to determine whether the signal to be processed belongs to a truncated signal. Specifically, the target process receiving the signal to be processed can be compared with the processes in the key process list in the policy configuration file. If there is a first process in the key process list that matches the target process receiving the signal to be processed, the identifier of the signal to be processed can be matched with the signal corresponding to the first process in the policy configuration file, and based on the processing strategy corresponding to the signal matching the signal to be processed, it is determined whether the signal to be processed belongs to a truncated signal. Among them, the policy configuration file can be as shown in Table 2 in the above embodiment.

[0111] In a possible example, if the processing strategy corresponding to the signal identifier that matches the identifier of the signal to be processed is "truncate the signal", it can be determined that the signal to be processed is a truncation signal. At this time, the signal to be processed needs to be truncate, specifically, the operating system kernel needs to skip the sending process of the signal to be processed to avoid storing the signal to be processed in the signal queue of the target process that receives the signal to be processed.

[0112] If the target process receiving the signal to be processed does not belong to the processes in the key process list, or the target process receiving the signal to be processed belongs to the process in the key process list, but the signal identifier corresponding to the key process matching the target process receiving the signal to be processed does not contain an identifier that matches the identifier of the signal to be processed. At this time, it can be determined that the signal to be processed is not a truncated signal. Or there is an identifier that matches the signal to be processed in the signal corresponding to the key process matching the target process receiving the signal to be processed, but it can be determined that the signal to be processed is not a truncated signal based on the processing strategy corresponding to the signal. In the case that the signal to be processed does not belong to a truncated signal, it is not necessary to perform any processing on the signal to be processed, and the operating system kernel continues to execute the signal to be processed.

[0113] In one possible example, when writing an eBPF program, you can pre-set the operations that trigger the kernel to execute after the eBPF program returns to the kernel under different circumstances. For example, when the eBPF program needs to trigger the kernel to continue executing the current signal, the eBPF program can return to the kernel, and the kernel will continue to execute the sending process of the pending signal. The eBPF program can modify the return value of the kernel signal sending function call function, so that the signal sending function returns directly without actually adding the signal to the process's signal queue, thereby achieving the purpose of signal truncation.

[0114] When it is determined that the signal to be processed does not belong to the truncated signal, the kernel will continue to execute the sending process of the signal to be processed, add the signal to be processed to the signal queue of the target process that receives the signal to be processed, and execute it. For the signal to be processed executed by the operating system kernel, it is also necessary to determine whether the signal to be processed needs to be processed. First, it is necessary to determine whether the received signal to be processed belongs to an alarm signal. Specifically, the identifier of the received signal to be processed can be matched with the signal identifier in the alarm signal list in sequence. If there is a signal identifier in the alarm signal list that matches the identifier of the signal to be processed, it is determined that the signal to be processed belongs to the signal in the alarm signal list. Among them, the alarm signal list can be as shown in Table 3 in the above embodiment, and the signal in the alarm signal list can be configured by the system administrator or other processes through the corresponding interface.

[0115] In one possible example, when it is determined that the received signal to be processed belongs to a signal in the alarm signal list, it is also necessary to obtain the alarm count of the signal to be processed. If the alarm count of the signal to be processed is greater than or equal to the first threshold, it is necessary to suppress the signal to be processed from alarming, and record the number of times the signal to be processed is suppressed from alarming. If the alarm count of the signal to be processed is less than the first threshold, it is necessary to update the alarm count of the signal to be processed. Then, alarm information is generated based on the associated information of the signal to be processed, and the alarm information is reported through a preset alarm interface.

[0116] Before issuing an alarm, the alarm frequency of the signal requiring an alarm is compared with a preset first threshold value, and an alarm is issued only when the alarm frequency of the signal requiring an alarm is less than the first threshold value, thereby avoiding the alarm reporting module from issuing frequent alarms for the same signal in a short period of time.

[0117] Next, a process management method provided by an embodiment of the present application is introduced with a specific example. The method can be applied to Figure 4 The computing device shown. Exemplary, Figure 7 A flowchart of a process management method provided by an embodiment of the present application is shown. Figure 7 The method includes: step 701-step 709.

[0118] Step 701, obtaining a signal to be processed in the operating system kernel.

[0119] In this embodiment, the signal processing process in the memory can be tracked through the eBPF mechanism to obtain all pending signals of the process in the kernel. Specifically, the precompiled eBPF kernel state component can be pre-mounted on the function of the kernel signal sending process. When the process sends a signal and enters the kernel through a system call, the signal entering the kernel can be captured through eBPF.

[0120] Step 702 , determining whether the acquired signal to be processed belongs to a signal in the monitoring signal list, if so, executing step 703 , otherwise executing step 709 .

[0121] In this embodiment, after obtaining the signal to be processed in the kernel, it is also necessary to determine whether the obtained signal to be processed belongs to the signal in the monitoring signal list. If the obtained signal to be processed belongs to the signal in the monitoring signal list, it is necessary to further analyze and process the signal to be processed. If the obtained signal to be processed does not belong to the signal in the monitoring signal list, it is not necessary to further process the signal to be processed, and the operating system kernel continues to execute the signal to be processed.

[0122] Among them, the signals in the monitoring signal list can be configured by the system administrator or other processes through the corresponding configuration interface.

[0123] Step 703: Analyze the signal to be processed to obtain relevant information of the signal to be processed, and record the obtained relevant information of the signal to be processed into a log file of the operating system.

[0124] In this embodiment, when the signal to be processed belongs to a signal in the monitoring signal list, it is also necessary to analyze the signal to be processed and obtain the associated information of the signal to be processed. Among them, the associated information of the signal to be processed includes process call information and user information related to the signal to be processed. The process call information related to the signal to be processed includes: the source process that sends the signal, the call path of the signal, the target process that receives the signal, etc. Among them, the source process that sends the signal and the target process that receives the signal can be obtained by analyzing the signal to be processed. After obtaining the source process that sends the signal, the user information and the parent process of the source process that sends the signal can be obtained by analyzing the source process that sends the signal. By analyzing the parent process of the source process that sends the signal, the parent process of the parent process can be obtained, and the call path of the signal sender can be obtained by recursive analysis.

[0125] After obtaining the associated information of the signal to be processed, it is also necessary to record the associated information of the signal to be processed into the system log of the operating system to facilitate the operation and maintenance personnel to quickly trace the execution signal.

[0126] Step 704, determining whether the signal to be processed is a truncated signal, if it is a truncated signal, executing step 705, otherwise executing step 706.

[0127] In this embodiment, the truncation signal refers to a signal that requires the operating system to abandon execution. For the truncation signal, after the truncation signal enters the operating system kernel, the signal needs to be captured and discarded, that is, the truncation signal cannot be stored in the signal queue of the corresponding process.

[0128] After determining that the signal to be processed belongs to the signal in the monitoring signal list, it is also necessary to determine whether the signal to be processed belongs to a truncated signal. Specifically, it is first necessary to determine to compare the target process receiving the signal to be processed with the processes in the key process list in the policy configuration file to determine whether there is a process in the key process list that matches the target process receiving the signal to be processed. If there is no process in the key process list that matches the target process receiving the signal to be processed, the signal to be processed does not belong to a truncated signal.

[0129] If there is a first process in the key process list that matches the target process that receives the signal to be processed, it is necessary to further judge the process of the signal to be processed. Specifically, the signal to be processed can be matched with the signal corresponding to the first process in the policy configuration file. If there is no signal matching the signal to be processed among the signals corresponding to the first process, the signal to be processed does not belong to a truncated signal. If there is a first signal matching the identifier of the signal to be processed among the signals corresponding to the first process, it is also necessary to obtain the processing strategy corresponding to the first signal from the policy configuration file, and determine whether the signal to be processed belongs to a truncated signal based on the processing strategy corresponding to the first signal. For example, referring to Table 2 in the above embodiment, the processing strategy corresponding to the truncated signal is "truncated the signal".

[0130] It is understandable that there is no execution order between step 703 and step 704 .

[0131] Step 705, interrupt the process of processing the signal to be processed.

[0132] In this embodiment, when it is determined that the signal to be processed belongs to a truncated signal, at this time, the signal to be processed needs to be truncated. Specifically, the operating system kernel needs to skip the sending process of the signal to be processed to avoid storing the signal to be processed in the signal queue of the target process that receives the signal to be processed. For example, when writing an eBPF program, you can pre-set the operations that trigger the kernel to execute after the eBPF program returns to the kernel under different circumstances in the eBPF program. For example, when the eBPF program needs to trigger the kernel to continue executing the current signal, the eBPF program can return to the kernel and trigger the kernel to continue executing the sending process of the signal to be processed. The eBPF program can modify the return value of the kernel signal sending function call function, so that the signal sending function returns directly without actually adding the signal to the signal queue of the process, so as to achieve the purpose of signal truncation.

[0133] Step 706, determining whether the signal to be processed is an alarm signal, if it is an alarm signal, executing step 707, otherwise executing step 709.

[0134] In this embodiment, when it is determined that the signal to be processed does not belong to the truncated signal, it is also necessary to determine whether the signal to be processed belongs to an alarm signal. Specifically, the identifier of the signal to be processed can be matched with the signal identifier in the alarm signal list in sequence. If there is a signal identifier in the alarm signal list that matches the identifier of the signal to be processed, it is determined that the signal to be processed belongs to the signal in the alarm signal list. Among them, the signal in the alarm signal list can be configured by the system administrator or other processes through the corresponding configuration interface.

[0135] Step 707, determining whether the alarm number of the signal to be processed exceeds a first threshold, if not, executing step 708, otherwise executing step 709.

[0136] In this embodiment, after determining that the signal to be processed is an alarm signal, it is also necessary to obtain the alarm number of the signal to be processed, and compare the obtained alarm number of the signal to be processed with a preset first threshold.

[0137] It is understandable that the alarm count of each executed alarm signal is stored in the computing device, and the alarm count of the executed alarm signal is updated each time an alarm is reported.

[0138] Step 708: Generate alarm information of the signal to be processed according to the associated information of the signal to be processed, and report the alarm information through a preset alarm interface.

[0139] In this embodiment, when it is determined that the alarm number of the signal to be processed does not exceed the first threshold, an alarm needs to be issued for the signal to be processed. Specifically, alarm information of the signal to be processed can be generated according to the associated information of the signal to be processed, and the alarm information can be reported through a preset alarm interface.

[0140] The data arrangement module in the alarm reporting module can generate alarm information of the signal to be processed according to the information carried by the signal to be processed and the information collected by the information capture module. Then the generated alarm information is sent to the alarm push module in the alarm reporting module, and the alarm push module reports the alarm information through a preset alarm interface.

[0141] Step 709, triggering the operating system kernel to continue executing the signal to be processed.

[0142] In this embodiment, when the signal to be processed does not belong to the signal in the monitoring signal list, and the signal to be processed does not belong to the truncated signal, the operating system kernel will be triggered to continue executing the signal to be processed.

[0143] In an embodiment of the present application, the signal in the operating system kernel is tracked and captured, and the information of the captured signal is recorded in the system log, so that the subsequent operation and maintenance personnel can trace the source of the signal according to the information recorded in the system log. And the captured signal is analyzed, and when the captured signal belongs to an unexpected signal of a key process, the captured signal is shielded to ensure that the key business process is not unexpectedly closed. Finally, an alarm is issued for the specific signal executed by the kernel to improve the timeliness of the system exception handling.

[0144] It is understandable that the size of the sequence number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. In addition, in some possible implementations, each step in the above embodiment can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here. In addition, all or part of any feature in the above embodiment can be freely and arbitrarily combined without contradiction. The combined technical solution is also within the scope of the present application.

[0145] Based on the method in the above embodiment, an embodiment of the present application provides a computer-readable storage medium, which stores a computer program. When the computer program runs on a processor, the processor executes the method in the above embodiment.

[0146] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product, characterized in that when the computer program product runs on a processor, the processor executes the method in the above embodiment.

[0147] Based on the method in the above embodiment, the embodiment of the present application provides a computing device, which includes a motherboard and a chip. Among them, the chip is integrated on the motherboard, and the chip includes at least one memory for storing programs; at least one processor for executing the program stored in the memory, and when the program stored in the memory is executed, the processor is used to execute the method in the above embodiment. In the embodiment of the present application, the computing device can be a server, a server and other network devices.

[0148] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), CD-ROM or any other form of storage medium known in the art.

[0149] An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be an integral part of the processor. The processor and the storage medium can be located in an ASIC.

[0150] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0151] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

Claims

1. A process management method, characterized in that: The method comprises: Get pending signals of processes in the operating system kernel; When the signal to be processed matches the preset monitoring signal, obtaining the associated information of the signal to be processed; wherein the associated information includes process call information and user information related to the signal to be processed; Determine a target process that receives the signal to be processed based on process call information related to the signal to be processed; wherein the target process is a process that receives the signal to be processed; If there is a first process matching the target process in the preset key process list, determining whether the signal to be processed matches a signal corresponding to the first process; In the case where there is a first signal among the signals corresponding to the first process that matches the signal to be processed, obtaining a processing strategy corresponding to the first signal; Determining whether the signal to be processed is a truncated signal according to a processing strategy corresponding to the first signal; In the case that the signal to be processed is a truncated signal, truncation processing is performed on the signal to be processed.

2. The method according to claim 1, characterized in that The method further comprises: In a case where the signal to be processed does not belong to the truncated signal, the operating system kernel executes the signal to be processed.

3. The method according to claim 1 or 2, characterized in that: In the case where the signal to be processed does not belong to the truncated signal, the method further includes: Determining whether the signal to be processed is a preset alarm signal; In the case where the signal to be processed belongs to the preset alarm signal, generating alarm information according to the associated information of the signal to be processed; Report the alarm information.

4. The method according to claim 3, characterized in that The alarm information reported includes: Determining the alarm number of the signal to be processed; When the number of alarms is less than a first threshold, the alarm information is reported.

5. The method according to claim 4, characterized in that The method further comprises: When the number of alarms is greater than or equal to the first threshold, suppress reporting of the alarm information, and record the number of times the alarm of the signal to be processed is suppressed.

6. The method according to any one of claims 1-2, 4-5, characterized in that: The step of obtaining a signal to be processed by a process in the operating system kernel includes: The signal to be processed in the operating system kernel is obtained by extending the Berkeley Packet Filter eBPF.

7. The method according to any one of claims 1-2, 4-5, characterized in that: The process calling information related to the signal to be processed includes: one or more of: a source process sending the signal, a calling path of the signal, and a target process receiving the signal.

8. A computing device, characterized in that The computing device comprises a memory and a processor; the memory and the processor are coupled; The memory is used to store program instructions; The processor is used to execute the program instructions to perform the method according to any one of claims 1 to 7.

Images