Method, device and equipment for process management, medium and product

Abstract

The invention relates to the technical field of operating systems, and discloses a process management method, device and equipment, a medium and a product, the method comprises the following steps: if an ended first process exists, changing a parent process of a child process under the first process before changing the parent process of the child process under the first process; obtaining an orphan process recovery process of the namespace where the first process is located, an end reason identifier of the first process and a first sub-process list under the orphan process recovery process; after the parent process of the child processes under the first process is changed, a child process second list under the orphan process recovery process is obtained, and a to-be-recognized orphan process list is determined based on the first list and the second list; and based on the ending reason identifier, judging whether the first process exits normally, and if the ending reason identifier represents that the first process exits abnormally, ending the processes in the orphan process list to be identified. According to the method, the orphan process can be quickly and accurately positioned, and compared with the related technology of identifying the orphan process through polling, the method can reduce the identification overhead and improve the identification efficiency.

Description

Technical Field

[0001] The present invention relates to the technical field of operating systems, and in particular to methods, devices, equipment, media and products for process management. Background Art

[0002] In Linux, an orphan process is used to represent a situation where a parent process has exited, but a child process is still running. A daemon process is a special background process designed to run independently of its parent process and without terminal control. Orphan processes may not function properly and may not meet their design objectives. Their existence wastes Linux system resources, so they must be terminated. However, when terminating orphan processes, it is important to distinguish daemon processes that bear some resemblance to orphan processes to avoid accidentally shutting down daemon processes.

[0003] In related technologies, polling is used to periodically search for orphan processes in the system, determine whether the orphan process is malicious, and then shut down the orphan process. However, this polling method requires traversing many resources, cannot obtain the reason for the parent process's exit and handle it specifically, consumes a lot of resources, and does not handle orphan processes in a timely manner. Summary of the Invention

[0004] In view of this, the present invention provides a method, apparatus, equipment, medium and product for process management to solve the problem that the method of periodic polling to close orphan processes requires traversing many resources, cannot obtain the reason for the parent process to exit for targeted processing, consumes a lot of resources, and does not handle orphan processes in a timely manner.

[0005] In a first aspect, the present invention provides a method for process management, the method comprising: if there is a first process that has been terminated, before changing the parent process of the child process under the first process, obtaining the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process and the first list of child processes under the orphan process recovery process; after changing the parent process of the child process under the first process, obtaining the second list of child processes under the orphan process recovery process, and determining a list of orphan processes to be identified based on the first list and the second list; based on the termination reason identifier, judging whether the first process exited normally, and if the termination reason identifier indicates that the first process exited abnormally, terminating the processes in the list of orphan processes to be identified.

[0006] In an optional embodiment, judging whether the first process exits normally based on the termination reason identifier includes: if the termination reason identifier indicates that the first process exits normally, judging whether the orphan process recovery process is in the process whitelist; if the orphan process recovery process is not in the process whitelist, terminating the process in the orphan process list to be identified.

[0007] In an optional embodiment, if the termination reason identifier indicates that the first process exited normally, determining whether the orphan process recovery process is in the process whitelist includes: if the orphan process recovery process is in the process whitelist, sending the list of orphan processes to be identified to the user layer.

[0008] In an optional embodiment, the method further includes: sending the list of orphan processes to be identified to the user layer, waiting for a preset period of time, traversing the processes in the list of orphan processes to be identified, and determining whether the processes in the list of orphan processes to be identified point to the terminal; if the processes in the list of orphan processes to be identified point to the terminal, ending the processes in the list of orphan processes to be identified.

[0009] In an optional embodiment, the method also includes: creating a first hook function; if there is a first process that has been terminated, before changing the parent process of the child process under the first process, based on the first hook function, obtaining the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process, the first list of child processes under the orphan process recovery process, and the second list of child processes of the first process.

[0010] In an optional embodiment, the method also includes: creating a second hook function; based on the second hook function, obtaining a third list of sub-processes under the orphan process recovery process, and determining a list of orphan processes to be identified based on the third list, the first list and the second list.

[0011] In a second aspect, the present invention provides a device for process management, the device comprising: a first module for obtaining, if a first process is terminated, an orphan process recovery process in the namespace where the first process is located, an end reason identifier of the first process, and a first list of child processes under the orphan process recovery process before changing the parent process of the child process under the first process; a second module for obtaining, after changing the parent process of the child process under the first process, a second list of child processes under the orphan process recovery process, and determining a list of orphan processes to be identified based on the first list and the second list; a third module for judging whether the first process has exited normally based on the end reason identifier, and terminating the processes in the list of orphan processes to be identified if the end reason identifier indicates that the first process exited abnormally.

[0012] In a third aspect, the present invention provides a computer device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the method for process management of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0013] In a fourth aspect, the present invention provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the method for process management of the above-mentioned first aspect or any corresponding embodiment thereof.

[0014] In a fifth aspect, the present invention provides a computer program product comprising computer instructions for causing a computer to execute the method for process management according to the first aspect or any corresponding embodiment thereof.

[0015] The method, apparatus, device, medium and product for process management provided by this embodiment are implemented in kernel state. By comparing the child process lists before and after the parent process is changed and combining with the namespace isolation mechanism, orphan processes can be quickly and accurately located. Compared with the scheme of identifying orphan processes by polling in related technologies, the identification overhead can be reduced and the identification efficiency can be improved. At the same time, the method processes orphan processes at the same time as they are generated in the kernel execution flow, and terminates orphan processes that are accidentally created in real time, with high timeliness. In addition, for parent processes that exit abnormally, the orphan processes left behind are automatically cleaned up, which can prevent system resources from being occupied for a long time, reduce the consumption of system resources by zombie processes, and reduce the risk of system crashes due to poor process management. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] In order to more clearly illustrate the specific embodiments of the present invention or the technical solutions in related technologies, the following briefly introduces the drawings required for use in the specific embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0017] Figure 1 A schematic diagram of a process management method provided by the present application is shown; Figure 2 Another flowchart of the process management method provided by the present application is shown; Figure 3 A schematic diagram of the structure of the device for process management provided by the present application is shown; Figure 4 Schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. DETAILED DESCRIPTION

[0018] To make the purpose, technical solutions, and advantages of the embodiments of the present invention more clear, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present invention.

[0019] In the Linux system, when the parent process exits, the child process is remounted under the initial process and becomes an orphan process. The process ID (PID) of the initial (init) process is 1.

[0020] The characteristics of orphan processes include: first, the original parent process has exited. Since the original parent process of the orphan process has terminated, the parent process of the orphan process becomes the init process; second, the orphan process life cycle is independent, and the orphan process can continue to run until it is explicitly terminated after completing its task; third, orphan processes are usually not intentionally designed, but are the result of the program logic not correctly handling the parent-child process relationship.

[0021] A daemon process is a long-running process used to provide certain services, such as network (Web) services or database services.

[0022] The characteristics of a daemon process include: first, it is independent of the terminal. The daemon process is not related to any terminal and will not be affected by the terminal closing; second, it is usually started and managed by the system initialization process init or systemd; third, it is a background service designed by the developer to perform specific tasks; fourth, it is created according to standard steps. Creating a daemon process requires following a series of standard steps, including calling fork() and letting the parent process exit, calling setsid() to create a new session, detaching from the controlling terminal, changing the working directory or file permission mask, etc.

[0023] The difference between orphan processes and daemon processes is shown in the following table, as shown in Table 1: Table 1 The difference between orphan processes and daemon processes

[0024] As shown in Table 1, orphan processes are caused by the exit of their parent process and are typically unintended. Daemons are intentionally created background processes through a series of standard steps to provide long-term services. The key differences between orphan processes and daemons lie in their intent, behavior, and purpose. Intention is reflected in the fact that orphan processes are accidental, while daemons are intentional. Behavior is reflected in the fact that orphan processes may remain associated with a terminal, while daemons must detach from the terminal. Purpose is reflected in the fact that orphan processes generally have no clear service objectives, while daemons are designed to provide a specific service.

[0025] According to an embodiment of the present invention, a method embodiment for process management is provided. It should be noted that the steps shown in the flowchart of the accompanying drawings can be executed in a computer system such as a set of computer executable instructions, and although a logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0026] In this embodiment, a method for process management is provided, which can be used in terminals such as mobile phones, tablet computers, desktop computers or laptop computers. Figure 1 A flow chart of the process management method provided by the present application is shown as follows: Figure 1 As shown, the process includes the following steps: Step S101: If there is a terminated first process, before changing the parent process of the child process under the first process, obtain the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process, and the first list of child processes under the orphan process recovery process.

[0027] In this step, the first process can be any process in the Linux kernel. When the call to the exit function (do_exit) is detected to terminate the first process, the orphan process reaper (child_reaper) of the namespace containing the first process is obtained. The orphan process reaper can be the first process in the current namespace, for example, the process with the process identifier (PID) 1 in the current namespace, a regular Linux systemd process, or the main business process of a container.

[0028] Specifically, the orphan process recovery process can be obtained through first process->thread_pid->numbers[first process->thread_pid->level]->ns->orphan process recovery process in the namespace where the first process is located.

[0029] The reason for the first process's termination is indicated by the exit_code flag of the first process. The first process may terminate normally or abnormally. If the first process terminates normally, the exit_code flag is zero. If the first process terminates abnormally, the exit_code flag is a non-zero positive value. The exit_code flag of a daemon process is typically also zero. This flag can be used to distinguish between normal daemon processes and unexpected orphaned processes.

[0030] Based on the first list of child processes under the orphan process recovery process, the existing child process list in the orphan process recovery process before the parent process of the child process under the first process is changed is represented, so that the orphan process newly added by this parent process change can be determined through the first list after the parent process of the child process under the first process is changed.

[0031] Step S102: After changing the parent process of the child process under the first process, obtain a second list of child processes under the orphan process recovery process, and determine a list of orphan processes to be identified based on the first list and the second list.

[0032] In this step, after obtaining the orphan process recovery process, the termination reason identifier of the first process, and the first list, the kernel changes the parent process of the child process under the first process through the kernel function (forget_original_parent), and changes the parent process of the child process under the first process from the first process to the orphan process recovery process.

[0033] After executing the parent process change operation based on the parent process change function, the child process list under the orphan process recovery process is obtained again, that is, the second list. The first list and the second list are compared to obtain the processes added to the second list compared to the first list, which is the orphan process list to be identified. The orphan process list to be identified can be obtained by the following method: Second list - first list = list of orphan processes to be identified The processes in the to-be-identified orphan process list are sub-processes of the first process that are reallocated to the orphan process recovery process after the first process is terminated.

[0034] Step S103: Based on the termination reason identifier, determine whether the first process exits normally. If the termination reason identifier indicates that the first process exits abnormally, terminate the process in the list of orphan processes to be identified.

[0035] In this step, if the termination reason identifier of the first process is a non-zero positive value, it indicates that the first process may have terminated unexpectedly, and a signal is sent to the processes in the list of orphan processes to be identified to terminate the processes in the list of orphan processes to be identified.

[0036] The method for process management provided by this embodiment is implemented in kernel state. By comparing the child process lists before and after the parent process is changed and combining with the namespace isolation mechanism, it can quickly and accurately locate orphan processes. Compared with the scheme of identifying orphan processes by polling in related technologies, it can reduce identification overhead and improve identification efficiency. At the same time, this method processes orphan processes at the same time as they are generated in the kernel execution flow, and terminates orphan processes that are accidentally created in real time, with high timeliness. In addition, for parent processes that exit abnormally, the orphan processes left behind are automatically cleaned up, which can prevent system resources from being occupied for a long time, reduce the consumption of system resources by zombie processes, and reduce the risk of system crashes due to poor process management.

[0037] In some optional implementations, based on the termination reason identifier, determining whether the first process exits normally includes: if the termination reason identifier indicates that the first process exits normally, determining whether the orphan process recovery process is in the process whitelist; if the orphan process recovery process is not in the process whitelist, terminating the process in the list of orphan processes to be identified.

[0038] In this embodiment, the process whitelist is used to represent a process capable of managing orphan processes, which can be a startup management process in a conventional Linux. Specifically, the whitelist can be preset to systemd or initd, etc., and the whitelist can be modified by the user.

[0039] If the first process exits normally and the orphan process recovery process is not in the process whitelist, it indicates that the orphan process recovery process is not a trustworthy process that can manage orphan processes. It is inappropriate to place the orphan process list to be identified under the orphan process recovery process, and the processes in the orphan process list to be identified need to be terminated.

[0040] In this way, on the basis of process management, a dynamic trust verification mechanism is added, which can prevent malicious takeover attacks using legal exit processes even if the first process exits normally; for unauthorized orphan process recycling processes, which may elevate their own permissions by controlling orphan processes, this solution uses a whitelist mechanism to ensure that only trusted processes can take over orphan processes, which can cut off such attack paths; in addition, the process whitelist mechanism has a very strong processing capability for container orphan processes, especially for orphan processes generated in business containers; thirdly, even if the system causes an abnormal process to become a recycling process due to configuration errors or component failures, the whitelist mechanism can promptly detect and terminate potential risks, thereby improving the system's fault tolerance.

[0041] In some optional implementations, based on the termination reason identifier, it is determined whether the first process exited normally. If the termination reason identifier indicates that the first process exited abnormally, the termination reason identifier is parsed, and based on the parsing result, the processes in the identified orphan process list are treated differently.

[0042] In this embodiment, if the termination reason identifier indicates that the first process is terminated due to hardware failure, the process running status data in the list of orphan processes to be identified can be stored in non-volatile storage; if the termination reason identifier indicates that the first process is terminated due to resource exhaustion, some orphan processes to be identified whose priority is lower than the preset priority threshold can be closed based on the preset resource priority.

[0043] In this way, compared to terminating all orphan processes uniformly, this solution processes the orphan processes to be identified based on the cause of the exception, which can maximize the preservation of key business data and service continuity; at the same time, the process status data saved during hardware failure can provide key clues for subsequent analysis, help locate hardware problems, and shorten fault repair time.

[0044] In some optional implementations, if the termination reason identifier indicates that the first process exited normally, determining whether the orphan process recovery process is in the process whitelist includes: if the orphan process recovery process is in the process whitelist, sending the list of orphan processes to be identified to the user layer.

[0045] In this embodiment, when the first process exits normally and the orphan process recovery process passes the whitelist verification, the system does not directly process the orphan process. Instead, it passes the list of orphan processes to be identified to the user layer. The transmission method can be implemented through a message queue, UNIX Domain Socket, a specific system application programming interface (API), or a log notification mechanism.

[0046] After receiving the list of orphan processes to be identified, the user layer can perform customized actions based on business needs. These actions include manual management, automated scripts, or logging and auditing. Manual management involves administrators using the command line or graphical user interface to retain, terminate, or migrate certain orphan processes. Automated scripts involve applications automatically handling specific types of orphan processes by monitoring system events, such as restarting critical services. Logging and auditing involves storing orphan process information in logs for compliance checks or performance analysis.

[0047] In this way, compared with the fixed process management method of unified termination or retention, this application gives the decision-making power to the user layer, allowing the processing logic to be customized according to business characteristics, which can improve business flexibility.

[0048] In some optional embodiments, the aforementioned method for process management also includes: sending the list of orphan processes to be identified to the user layer, waiting for a preset period of time, traversing the processes in the list of orphan processes to be identified, and determining whether the processes in the list of orphan processes to be identified point to the terminal; if the processes in the list of orphan processes to be identified point to the terminal, ending the processes in the list of orphan processes to be identified.

[0049] In this embodiment, the preset duration can be a few seconds or a few minutes, and can be determined based on actual usage requirements. Generally, a daemon process will not use a regular terminal as an input, output, or error output port, because the terminal may exit or switch, and output in the terminal may affect other processes using the terminal. Daemon processes will usually close input or redirect input to be meaningless, close output or redirect it to other files or inter-process communication (IPC), and close error output or redirect it to other files or IPC.

[0050] However, the daemon process may not complete the aforementioned shutdown or redirection work before the parent process ends, so it is possible to check once in a period of time in the user layer. If the input, output, or error output still points to the regular terminal, it means that such process is not a daemon process and a signal can be sent to end such process.

[0051] Specifically, the system traverses the list of orphan processes to be identified and determines whether any of the processes in the list are associated with a terminal. This determination may be made by checking the process's controlling terminal, determining whether the process has an open terminal device file, or analyzing the process's environment variables. If a process is found to be associated with a terminal, the process is identified as an orphan process and the current process is terminated.

[0052] In this way, orphan processes to be identified are automatically cleaned up through terminal detection. If an orphan process is identified, the process is terminated, which can avoid long-term resource occupation. It can also solve the problem of too many zombie terminals exhausting the maximum number of terminals allowed by the system, resulting in new users being unable to log in, thereby improving system availability.

[0053] In some optional embodiments, the aforementioned method for process management also includes: creating a first hook function; if there is a terminated first process, before changing the parent process of the child process under the first process, based on the first hook function, obtaining the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process, the first list of child processes under the orphan process recovery process, and the second list of child processes of the first process.

[0054] In this embodiment, a first hook function can be created and registered when the system is initialized, and the first hook function can be mounted in the callback chain of the parent process change function (forget_original_parent), such as the exit_notify mechanism of the Linux kernel. The first hook function is configured to be triggered after the first process ends but before the child process changes the parent process operation.

[0055] When it is detected that the first process is terminated, the first hook function is triggered, and the first hook function performs the following operations: locates and obtains the orphan process recovery process of the namespace where the first process is located through the namespace application program interface; reads the exit status code, kernel signal log or application layer error code of the first process, and parses it to obtain the termination reason identifier of the first process; obtains the first list of child processes of the orphan process recovery process.

[0056] In this way, the first hook function intervenes before the child process of the first process is changed to the parent process, which ensures that the data obtained by the first hook function can reflect the real process status; at the same time, the first hook function obtains the aforementioned data at one time through event-driven, which can reduce system call overhead and improve processing efficiency; in addition, directly obtaining data through kernel-level hooks can reduce the impact of external tool failures on process management and improve system robustness.

[0057] In some optional embodiments, the aforementioned method for process management also includes: creating a second hook function; based on the second hook function, obtaining a third list of sub-processes under the orphan process recovery process, and determining a list of orphan processes to be identified based on the third list, the first list and the second list.

[0058] In this embodiment, a second hook function can be created and registered when the system is initialized, and the second hook function can be mounted in the callback chain of the parent process change function (forget_original_parent), such as the exit_notify mechanism of the Linux kernel. The second hook function is configured to be triggered after the parent process of the child process under the first process is changed.

[0059] In this way, compared with the full-system process scanning method in related technologies, the second hook function can accurately locate the list of orphan processes to be identified, which can greatly reduce the traversal range and reduce system overhead; at the same time, in scenarios where processes are frequently created and destroyed, the second hook function can capture process tree changes in real time to ensure that orphan process identification is not interfered with by concurrent operations.

[0060] Combining the first hook function with the second hook function forms a complete process lifecycle monitoring closed loop, enabling accurate tracking of orphan processes. Solutions in related technologies usually rely only on single scans or static rules and cannot cope with complex dynamic environments. This solution calculates the child process lists at two different time points, solving the problems of how to distinguish true orphan processes from normal child processes, and how to avoid misjudgments and missed judgments in high-concurrency environments. Using kernel hooks to directly obtain process state changes can avoid the delays and uncertainties of user-space tools and achieve microsecond-level event response, which is particularly suitable for systems with high real-time requirements.

[0061] Figure 2 Another flow chart of the method for process management provided by this application is shown. Figure 2 As shown, the methods for process management include: Step S201, after the first process is ended, based on the first hook function, obtain the orphan process recovery process of the namespace where the first process is located, the information of the first process, the termination reason identifier of the first process and the first list of child processes under the orphan process recovery process.

[0062] Step S202 : Based on the parent process change function (forget_original_parent), the parent process of the child process under the first process is changed from the first process to the orphan process recovery process.

[0063] Step S203: After replacing the parent process for the child process of the first process, obtain a second list of child processes under the orphan process recovery process, and determine a list of orphan processes to be identified based on the child processes newly added to the second list compared to the first list.

[0064] Step S204, determine whether the end reason flag of the first process is zero, if not zero, go to step S205, if zero, go to step S206.

[0065] Step S205: Send a signal to terminate the process in the list of orphan processes to be identified.

[0066] Step S206, determine whether the orphan process recovery process is in the process whitelist, if not, go to step S205, if yes, go to step S207.

[0067] Step S207: Send the list of orphan processes to be identified to the user layer.

[0068] Step S208: Wait for a preset time period to exclude the daemon process from the list of orphan processes to be identified.

[0069] Step S209, determine whether the process in the to-be-identified orphan process list points to a regular terminal. If it does, proceed to step S210; if it does not, proceed to step S211.

[0070] Step S210: Send a signal to terminate the process pointing to the regular terminal in the list of orphan processes to be identified.

[0071] Step S211: determine that the process in the to-be-identified orphan process list that does not point to a regular terminal is not an orphan process.

[0072] In this embodiment, a device for process management is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments. Details already described will not be repeated here. As used below, the term "module" may refer to a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation using hardware, or a combination of software and hardware, is also possible and contemplated.

[0073] This embodiment provides a device for process management. Figure 3 The schematic diagram of the structure of the device for process management provided by the present application is shown as follows: Figure 3 As shown, including: The first module 301 is used to obtain the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process and the first list of child processes under the orphan process recovery process before changing the parent process of the child process under the first process if there is a terminated first process.

[0074] The second module 302 is configured to obtain a second list of child processes under the orphan process recovery process after changing the parent process of the child process under the first process, and determine a list of orphan processes to be identified based on the first list and the second list.

[0075] The third module 303 is configured to determine whether the first process exits normally based on the termination reason identifier, and terminate the processes in the to-be-identified orphan process list if the termination reason identifier indicates that the first process exits abnormally.

[0076] In some optional implementations, the third module 303 includes: The first unit of the third module is used to determine whether the orphan process recovery process is in the process whitelist if the end reason identifier indicates that the first process exited normally; if the orphan process recovery process is not in the process whitelist, end the process in the orphan process list to be identified.

[0077] In some optional embodiments, the first unit of the third module includes: The first sub-unit of the third module is used to send the list of orphan processes to be identified to the user layer if the orphan process recovery process is in the process whitelist.

[0078] In some optional implementations, the aforementioned apparatus for process management further includes: The sending module is used to send the list of orphan processes to be identified to the user layer, wait for a preset time, traverse the processes in the list of orphan processes to be identified, and determine whether the processes in the list of orphan processes to be identified point to the terminal; if the processes in the list of orphan processes to be identified point to the terminal, end the processes in the list of orphan processes to be identified.

[0079] In some optional implementations, the aforementioned apparatus for process management further includes: The first creation module is used to create a first hook function; if there is a terminated first process, before changing the parent process of the child process under the first process, based on the first hook function, obtain the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process, the first list of child processes under the orphan process recovery process, and the second list of child processes of the first process.

[0080] In some optional implementations, the aforementioned apparatus for process management further includes: The second creation module is used to create a second hook function; based on the second hook function, obtain the third list of child processes under the orphan process recovery process, and determine the list of orphan processes to be identified based on the third list, the first list and the second list.

[0081] The further functional description of each of the above modules and units is the same as that of the above corresponding embodiments and will not be repeated here.

[0082] The device for process management in this embodiment is presented in the form of a functional unit, where the unit refers to an application-specific integrated circuit (ASIC) circuit, a processor and memory that executes one or more software or fixed programs, and / or other devices that can provide the above functions.

[0083] The embodiment of the present invention also provides a computer device having the above Figure 3 The apparatus for process management is shown.

[0084] See also Figure 4 , Figure 4 is a structural diagram of a computer device provided by an optional embodiment of the present invention, such as Figure 4 As shown, the computer device includes: one or more processors 10, a memory 20, and interfaces for connecting various components, including high-speed interfaces and low-speed interfaces. Various components utilize different buses to communicate with each other and can be installed on a common mainboard or installed in other ways as needed. The processor can process the instructions executed in the computer device, including instructions stored in or on the memory to display the graphical information of a graphical user interface on an external input / output device (such as, a display device coupled to the interface). In some optional embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Equally, multiple computer devices can be connected, and each device provides part of the necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). Figure 4 A processor 10 is taken as an example.

[0085] The processor 10 may be a central processing unit, a network processor, or a combination thereof. The processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit, a programmable logic device, or a combination thereof. The programmable logic device may be a complex programmable logic device, a field programmable gate array, a general purpose array logic, or any combination thereof.

[0086] The aforementioned memory 20 stores instructions that can be executed by at least one processor 10, so that the aforementioned at least one processor 10 executes the method shown in the above embodiment.

[0087] The memory 20 may include a program storage area and a data storage area, wherein the program storage area may store an operating system and application programs required for at least one function; the data storage area may store data created based on the use of the computer device, etc. In addition, the memory 20 may include a high-speed random access memory, and may also include a non-transient memory, such as at least one disk storage device, a flash memory device, or other non-transient solid-state storage device. In some optional embodiments, the memory 20 may optionally include a memory remotely located relative to the processor 10, and these remote memories may be connected to the computer device via a network. Examples of the above-mentioned network include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0088] The memory 20 may include a volatile memory, such as a random access memory; the memory may also include a non-volatile memory, such as a flash memory, a hard disk or a solid-state drive; the memory 20 may also include a combination of the above types of memory.

[0089] The computer device also includes an input device 30 and an output device 40. The processor 10, the memory 20, the input device 30 and the output device 40 can be connected via a bus or other means. Figure 4 The bus connection is taken as an example.

[0090] The input device 30 can receive input digital or character information and generate key signal input related to user settings and function control of the computer device. Examples include a touch screen, keypad, mouse, trackpad, touchpad, pointing stick, one or more mouse buttons, trackball, joystick, etc. The output device 40 may include a display device, auxiliary lighting device (e.g., light-emitting diodes), and tactile feedback device (e.g., a vibration motor). Such display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, monitors, and plasma displays. In some optional embodiments, the display device may be a touch screen.

[0091] The embodiment of the present invention also provides a computer-readable storage medium. The above-mentioned method according to the embodiment of the present invention can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the method shown in the above embodiment is implemented.

[0092] A portion of the present invention may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present invention through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes, but is not limited to, a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes, but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium may be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0093] Although the embodiments of the present invention have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present invention. Such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A method for process management, characterized in that The method comprises: If there is a terminated first process, before changing the parent process of the child process under the first process, obtaining the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process, and the first list of child processes under the orphan process recovery process; After changing the parent process of the child process under the first process, obtaining a second list of child processes under the orphan process recovery process, and determining a list of orphan processes to be identified based on the first list and the second list; Based on the termination reason identifier, it is determined whether the first process exits normally; if the termination reason identifier indicates that the first process exits abnormally, the processes in the to-be-identified orphan process list are terminated.

2. The method according to claim 1, characterized in that The determining, based on the termination reason identifier, whether the first process exits normally includes: If the termination reason identifier indicates that the first process exited normally, determining whether the orphan process recovery process is in the process whitelist; If the orphan process recovery process is not in the process whitelist, terminate the processes in the to-be-identified orphan process list.

3. The method according to claim 2, characterized in that If the termination reason identifier indicates that the first process exited normally, determining whether the orphan process recovery process is in the process whitelist includes: If the orphan process recovery process is in the process whitelist, the list of orphan processes to be identified is sent to the user layer.

4. The method according to claim 3, characterized in that The method further comprises: Send the orphan process list to be identified to the user layer, wait for a preset time, traverse the processes in the orphan process list to be identified, and determine whether the process in the orphan process list to be identified points to the terminal; If a process in the to-be-identified orphan process list points to a terminal, terminate the process in the to-be-identified orphan process list.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Create the first hook function; If there is a terminated first process, before changing the parent process of the child process under the first process, based on the first hook function, obtain the orphan process recovery process of the namespace where the first process is located, the termination reason identifier of the first process, the first list of child processes under the orphan process recovery process, and the second list of child processes of the first process.

6. The method according to any one of claims 1 to 4, characterized in that The method further comprises: Create the second hook function; Based on the second hook function, a third list of child processes under the orphan process recovery process is obtained, and based on the third list, the first list and the second list, a list of orphan processes to be identified is determined.

7. A device for process management, characterized in that The device comprises: A first module is configured to, if a terminated first process exists, obtain an orphan process recovery process in a namespace where the first process is located, an identifier of a termination reason for the first process, and a first list of child processes under the orphan process recovery process before changing a parent process of a child process under the first process; A second module is configured to obtain a second list of child processes under the orphan process recovery process after changing the parent process of the child process under the first process, and determine a list of orphan processes to be identified based on the first list and the second list; The third module is configured to determine whether the first process exits normally based on the termination reason identifier, and terminate the processes in the to-be-identified orphan process list if the termination reason identifier indicates that the first process exits abnormally.

8. A computer device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the method for process management according to any one of claims 1 to 6 by executing the computer instructions.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the method for process management according to any one of claims 1 to 6.

10. A computer program product, characterized in that The method comprises computer instructions for causing a computer to execute the method for process management according to any one of claims 1 to 6.

Images