Methods, apparatus, devices, media, and products for process management

Abstract

This invention relates to the field of operating system technology, and discloses a method, apparatus, device, medium, and product for process management. The method includes: if a first process has been terminated, before changing the parent process of child processes under the first process, obtaining the orphan process recycling process in the namespace where the first process resides, the termination reason identifier of the first process, and a first list of child processes under the orphan process recycling process; after changing the parent process of child processes under the first process, obtaining a second list of child processes under the orphan process recycling process; based on the first and second lists, determining a list of orphan processes to be identified; based on the termination reason identifier, determining whether the first process exited normally; if the termination reason identifier indicates that the first process exited abnormally, terminating the processes in the list of orphan processes to be identified. This method can quickly and accurately locate orphan processes, and compared with related technologies that identify orphan processes by polling, it can reduce identification overhead and improve identification efficiency.

Description

Technical Field

[0001] This invention relates to the field of operating system technology, and more specifically to methods, apparatus, devices, media, and products for process management. Background Technology

[0002] In Linux systems, orphan processes are processes whose parent processes have exited but whose child processes are still running. Daemon processes, on the other hand, are special background processes designed to run independently of their parent processes and without terminal control. Orphan processes may not function correctly and may not be intended to perform their purpose. Their existence wastes Linux system resources, so they need to be terminated. However, during the termination process, it's crucial to distinguish between orphan processes and daemon processes that share similarities to them, and to avoid accidentally terminating daemon processes.

[0003] In related technologies, polling is used to periodically search for orphan processes in the system, determine whether an orphan process is malicious, and then close it. However, periodic polling requires traversing many resources, cannot obtain the reason for the parent process's exit for targeted handling, consumes a lot of resources, and is not timely in handling orphan processes. Summary of the Invention

[0004] In view of this, the present invention provides a method, apparatus, device, medium and product for process management to solve the problems of the timed polling to close orphan processes, which requires traversing many resources, cannot obtain the reason for the parent process's exit for 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 terminated first process, before changing the parent process of child processes under the first process, obtaining an orphan process recycling process in the namespace where the first process is located, an termination reason identifier of the first process, and a first list of child processes under the orphan process recycling process; after changing the parent process of child processes under the first process, obtaining a second list of child processes under the orphan process recycling process; determining a list of orphan processes to be identified based on the first list and the second list; determining whether the first process exited normally based on the termination reason identifier; 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 one optional implementation, determining whether the first process exited normally based on the termination reason identifier includes: if the termination reason identifier indicates that the first process exited normally, determining whether the orphan process recycling process is in the process whitelist; if the orphan process recycling process is not in the process whitelist, terminating the process in the list of orphan processes to be identified.

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

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

[0009] In an optional implementation, the method further includes: creating a first hook function; if there is a terminated first process, before changing the parent process of the child processes under the first process, based on the first hook function, obtaining the orphan process recycling 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 recycling process, and the second list of child processes of the first process.

[0010] In an optional implementation, the method further includes: creating a second hook function; obtaining a third list of child processes under the orphan process recycling process based on the second hook function; and determining a list of orphan processes to be identified based on the third list, the first list, and the second list.

[0011] Secondly, the present invention provides an apparatus for process management, the apparatus comprising: a first module, configured to, if a terminated first process exists, before changing the parent process of child processes under the first process, obtain an orphan process recycling process in the namespace where the first process resides, an termination reason identifier of the first process, and a first list of child processes under the orphan process recycling process; a second module, configured to, after changing the parent process of child processes under the first process, obtain a second list of child processes under the orphan process recycling process, and determine a list of orphan processes to be identified based on the first list and the second list; and a third module, configured to, based on the termination reason identifier, determine whether the first process exited normally, and if the termination reason identifier indicates that the first process exited abnormally, terminate the processes in the list of orphan processes to be identified.

[0012] Thirdly, 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 computer instructions to perform the method for process management described in the first aspect or any corresponding embodiment thereof.

[0013] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions for causing a computer to perform the process management method of the first aspect or any corresponding embodiment thereof.

[0014] Fifthly, the present invention provides a computer program product, including computer instructions for causing a computer to execute the method for process management described in the first aspect or any corresponding embodiment thereof.

[0015] The method, apparatus, device, medium, and product for process management provided in this embodiment are implemented in kernel mode. By comparing the child process lists before and after the parent process change, combined with the namespace isolation mechanism, orphan processes can be located quickly and accurately. Compared with the polling-based identification of orphan processes in related technologies, this method can reduce identification overhead and improve identification efficiency. At the same time, this method processes orphan processes in the kernel execution flow at the same time as they are created, terminating accidentally created orphan processes in real time, which is highly efficient. In addition, for parent processes that exit abnormally, the method automatically cleans up the orphan processes left behind, 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 caused by poor process management. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the specific embodiments or related technologies of the present invention, the drawings used in the description of the specific embodiments or related technologies will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0017] Figure 1 A flowchart illustrating the process management method provided in this application is shown.

[0018] Figure 2 Another flowchart illustrating the process management method provided in this application is shown;

[0019] Figure 3 A schematic diagram of the structure of the apparatus for process management provided in this application is shown;

[0020] Figure 4 This is a schematic diagram of the hardware structure of a computer device according to an embodiment of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] In Linux systems, when the parent process exits, the child process is reattached to the initial process and becomes an orphan process. The process ID (PID) of the initial (init) process is 1.

[0023] 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 life cycle of an orphan process is independent. An 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 handling the parent-child process relationship correctly.

[0024] A daemon is a long-running process that provides a certain service, such as providing network (web) services or database services.

[0025] The characteristics of daemons include: First, they are detached from the terminal; daemons are independent of any terminal and are not affected by the terminal being closed. Second, they are usually started and managed by the system initialization process init or systemd. Third, they are background services designed by developers to perform specific tasks. Fourth, they are created following standard procedures; creating a daemon 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, and changing the working directory or file permission mask, etc.

[0026] The differences between orphan processes and daemon processes are shown in the following table, as shown in Table 1:

[0027] Table 1. Differences between orphan processes and daemon processes

[0028]

[0029] As shown in Table 1, orphan processes are caused by the exit of their parent process and are usually an unintentional result. Daemon processes, on the other hand, are background processes intentionally created through a series of standard procedures to provide long-term services. The key differences between orphan processes and daemons lie in their intent, behavior, and purpose. In terms of intent, orphan processes are unintended consequences, while daemons are intentionally designed. In terms of behavior, orphan processes may still be associated with the terminal, while daemons must detach from the terminal. In terms of purpose, orphan processes typically lack a clear service goal, while daemons are designed to provide a specific service.

[0030] 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 in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0031] This embodiment provides a method for process management, which can be used on terminals such as mobile phones, tablets, desktop computers, or laptops. Figure 1 A flowchart illustrating the process management method provided in this application is shown, as follows: Figure 1 As shown, the process includes the following steps:

[0032] Step S101: If there is a terminated first process, before changing the parent process of the child processes under the first process, obtain the orphan process recycling 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 recycling process.

[0033] In this step, the first process can be any process in the Linux kernel. When it is detected that the first process has been terminated by calling the termination function (do_exit), the orphan process reclaimer (child_reaper) of the namespace where the first process is located is obtained. The orphan process reclaimer can be the first process in the current namespace, such as the process with the process ID (PID) of 1 in the current namespace, or a regular Linux systemd process, the main business process of a container, etc.

[0034] Specifically, the orphan process recycling process can be obtained by going to the first process -> thread_pid -> numbers [first process -> thread_pid -> level] -> ns -> orphan process recycling process in the namespace where the first process is located.

[0035] The exit reason code (exit_code) of the first process indicates why the first process was terminated. The first process may terminate normally or abnormally. If the first process terminates normally, the exit reason code is zero; if the first process terminates abnormally, the exit reason code is a non-zero positive value. Meanwhile, the exit reason code of a daemon process is usually also zero. The exit reason code can also be used to distinguish between normal daemon processes and unexpected orphan processes.

[0036] The first list of child processes under the orphan process reclamation process represents the existing list of child processes in the orphan process reclamation process before changing the parent process of the child processes under the first process. This is convenient for identifying the newly added orphan processes after changing the parent process of the child processes under the first process by using the first list.

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

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

[0039] After performing the parent process change operation based on the parent process change function, the list of child processes under the orphan process recycling process is obtained again, i.e., the second list. The second list is compared with the first list to obtain the list of processes added to the second list compared to the first list; this is the list of orphan processes to be identified. The list of orphan processes to be identified can be obtained in the following way:

[0040] Second list - First list = List of processes for identifying orphans

[0041] The processes in the list of orphan processes to be identified are the child processes of the first process that were terminated and then reassigned to the orphan process recycling process.

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

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

[0044] The process management method provided in this embodiment is implemented in kernel mode. By comparing the child process lists before and after the parent process change, combined with the namespace isolation mechanism, it can quickly and accurately locate orphan processes. Compared with the polling-based identification of orphan processes in related technologies, it can reduce identification overhead and improve identification efficiency. At the same time, this method processes orphan processes in the kernel execution flow at the same time as they are created, terminating accidentally created orphan processes in real time, which is highly efficient. In addition, for parent processes that exit abnormally, it automatically cleans up their residual orphan processes, 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 caused by poor process management.

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

[0046] In this implementation, the process whitelist is used to identify processes capable of managing orphan processes, and can be a regular Linux startup management process. Specifically, the whitelist can be preset to systemd or initd, and can be modified by the user.

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

[0048] In this way, a dynamic trust verification mechanism is added to the process management, which can prevent malicious takeover attacks that exploit the legitimate exit process even if the first process exits normally. For unauthorized orphan processes that are being recycled, which may escalate their own privileges by controlling orphan processes, this solution uses a whitelist mechanism to ensure that only trusted processes can take over orphan processes, thus cutting off such attack paths. In addition, the process whitelist mechanism has a very strong ability to handle orphan processes in containers, especially those generated in business containers. Furthermore, even if an abnormal process becomes a recycled process due to system misconfiguration or component failure, the whitelist mechanism can promptly detect and terminate potential risks, improving the system's fault tolerance.

[0049] 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 list of orphan processes to be identified are processed differently.

[0050] In this embodiment, if the termination reason flag indicates that the first process was terminated due to a 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 flag indicates that the first process was terminated due to resource exhaustion, some orphan processes to be identified with a priority lower than a preset priority threshold can be closed based on a preset resource priority.

[0051] In this way, compared to uniformly terminating all orphan processes, this solution processes orphan processes to be identified based on the cause of the anomaly, which can preserve the continuity of critical business data and services to the greatest extent. 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 the fault repair time.

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

[0053] In this implementation, when the first process exits normally and the orphan process reclamation process passes the whitelist verification, the system does not directly process the orphan processes. Instead, it passes the list of orphan processes to be identified to the user layer. This passing can be achieved through mechanisms such as message queues, UNIX Domain Sockets, specific system application programming interfaces (APIs), or log notifications.

[0054] After receiving the list of orphaned processes to be identified, the user layer can perform custom operations based on business needs. These custom operations include manual management, automated scripts, and log auditing. Manual management allows administrators to select, retain, terminate, or migrate some orphaned processes via command line or graphical interface. Automated scripts allow applications to automatically handle specific types of orphaned processes by listening for system events, such as restarting critical services. Log auditing involves storing orphaned process information in logs for compliance checks or performance analysis.

[0055] In this way, compared with a fixed process management approach that uniformly terminates or retains processes, this application delegates the decision-making power to the user layer, allowing for customized processing logic based on business characteristics, which can improve business flexibility.

[0056] In some optional implementations, the aforementioned method for process management further includes: sending a list of orphan processes to be identified to the user layer, waiting for a preset time, traversing the processes in the list of orphan processes to be identified, and determining whether a process in the list of orphan processes to be identified points to a terminal; if a process in the list of orphan processes to be identified points to a terminal, terminating the process in the list of orphan processes to be identified.

[0057] In this implementation, the preset duration can be a few seconds or a few minutes, which can be determined based on actual usage needs. Typically, daemons do not use regular terminals as input, output, or error output ports because terminals may exit or switch, and output to a terminal may affect other processes using the terminal. Daemons usually disable input or redirect input to meaningless values, disable or redirect output to other files or inter-process communication (IPC), and disable or redirect error output to other files or IPC.

[0058] However, a daemon process may not have completed the aforementioned shutdown or redirection work before the parent process terminates. Therefore, it is possible to check at intervals in the user layer. If the input, output, or error output still points to the regular terminal, it means that this type of process is not a daemon process, and a signal can be sent to terminate this type of process.

[0059] Specifically, the list of orphan processes to be identified is traversed to determine whether a process in the list is associated with a terminal. This determination can be made by checking the process's controlling terminal, determining if the process has any open terminal device files, or analyzing the process's environment variables. If a process is found to be pointing to a terminal, it is considered an orphan process, and the current process is terminated.

[0060] In this way, by automatically cleaning up orphan processes to be identified through terminal detection, and terminating the process if it is identified as an orphan process, we can avoid the long-term occupation of resources and solve the problem of too many zombie terminals exhausting the maximum number of terminals allowed by the system, which would prevent new users from logging in, thus improving the availability of the system.

[0061] In some optional implementations, the aforementioned method for process management further includes: creating a first hook function; if there is a terminated first process, before changing the parent process of the child processes under the first process, based on the first hook function, obtaining the orphan process recycling 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 recycling process, and the second list of child processes of the first process.

[0062] In this implementation, a first hook function can be created and registered during system initialization. The first hook function is then attached to the callback chain of the parent process change function (forget_original_parent), such as in the Linux kernel's exit_notify mechanism. The first hook function is configured to be triggered before the child process changes its parent process after the first process ends.

[0063] When the termination of the first process is detected, the first hook function is triggered. The first hook function performs the following operations: locates and obtains the orphan process recycling process in the namespace where the first process is located through the namespace application programming 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; and obtains the first list of child processes of the orphan process recycling process.

[0064] In this way, by intervening before the child process of the first process is modified by the operation of the parent process, it can be ensured that the data obtained by the first hook function can reflect the real process state. At the same time, the first hook function obtains the aforementioned data all at once through event-driven operation, which can reduce system call overhead and improve processing efficiency. In addition, obtaining data directly through kernel-level hooks can reduce the impact of external tool failures on process management and improve system robustness.

[0065] In some optional implementations, the aforementioned method for process management further includes: creating a second hook function; obtaining a third list of child processes under the orphan process recycling process based on the second hook function; and determining a list of orphan processes to be identified based on the third list, the first list, and the second list.

[0066] In this implementation, a second hook function can be created and registered during system initialization. The second hook function is then attached to the callback chain of the function that changes the parent process (forget_original_parent), such as the exit_notify mechanism in the Linux kernel. The second hook function is configured to be triggered after the change of the parent process of the child process under the first process is completed.

[0067] In this way, compared with the whole system process scanning method in related technologies, the second hook function can accurately locate the list of orphan processes to be identified, which can significantly 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 changes in the process tree in real time, ensuring that the identification of orphan processes is not affected by concurrent operations.

[0068] By combining the first and second hook functions, a complete process lifecycle monitoring loop is formed, enabling precise tracking of orphan processes. Related technologies typically rely on single scans or static rules, which are insufficient for complex dynamic environments. This solution uses child process lists at two different time points to perform calculations, solving the problems of distinguishing between truly orphan processes and normal child processes, and avoiding false positives and false negatives in high-concurrency environments. Utilizing kernel hooks to directly obtain process state changes avoids the latency and uncertainty of user-space tools, achieving microsecond-level event response, making it particularly suitable for systems with high real-time requirements.

[0069] Figure 2 Another flowchart illustrating the process management method provided in this application is shown. Figure 2 As shown, the methods used for process management include:

[0070] Step S201: After the first process is terminated, based on the first hook function, obtain the orphan process recycling 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 recycling process.

[0071] 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 recycling process.

[0072] Step S203: After changing the parent process of the child processes of the first process, obtain the second list of child processes under the orphan process recycling process, and determine the list of orphan processes to be identified based on the child processes added in the second list compared with the first list.

[0073] Step S204: Determine whether the termination reason flag of the first process is zero. If it is not zero, proceed to step S205. If it is zero, proceed to step S206.

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

[0075] Step S206: Determine whether the orphan process recycling process is in the process whitelist. If not, proceed to step S205; if so, proceed to step S207.

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

[0077] Step S208: Wait for a preset time and exclude daemons from the list of orphan processes to be identified.

[0078] Step S209: Determine whether a process in the list of orphan processes to be identified points to a regular terminal. If it points to a regular terminal, proceed to step S210; otherwise, proceed to step S211.

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

[0080] Step S211: Determine that processes in the list of orphan processes to be identified that do not point to a regular terminal are not orphan processes.

[0081] This embodiment also provides a process management apparatus for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that performs a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0082] This embodiment provides a device for process management. Figure 3 A schematic diagram of the structure of the device for process management provided in this application is shown, such as... Figure 3 As shown, it includes:

[0083] The first module 301 is used to obtain, before changing the parent process of the child processes under the first process, the orphan process recycling 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 recycling process if there is a terminated first process.

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

[0085] The third module 303 is used to determine whether the first process exited normally based on the termination reason identifier. If the termination reason identifier indicates that the first process exited abnormally, the process in the list of orphan processes to be identified is terminated.

[0086] In some alternative implementations, the third module 303 includes:

[0087] The first unit of the third module is used to determine whether the process to be reclaimed as an orphan process is in the process whitelist if the termination reason flag indicates that the first process has exited normally; if the process to be reclaimed as an orphan process is not in the process whitelist, the process in the list of orphan processes to be identified is terminated.

[0088] In some alternative implementations, the first unit of the third module includes:

[0089] The first subunit of the third module is used to send the list of orphan processes to be identified to the user layer if the orphan process recycling process is in the process whitelist.

[0090] In some alternative implementations, the aforementioned apparatus for process management further includes:

[0091] The sending module is used to send the list of orphan processes to be identified to the user layer. After waiting for a preset time, it iterates through the processes in the list of orphan processes to be identified and determines whether a process in the list of orphan processes points to a terminal. If a process in the list of orphan processes points to a terminal, the process in the list of orphan processes to be identified is terminated.

[0092] In some alternative implementations, the aforementioned apparatus for process management further includes:

[0093] The first creation module is used to create the first hook function. If there is a terminated first process, before changing the parent process of the child processes under the first process, based on the first hook function, the orphan process recycling 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 recycling process, and the second list of child processes of the first process are obtained.

[0094] In some alternative implementations, the aforementioned apparatus for process management further includes:

[0095] The second creation module is used to create the second hook function; based on the second hook function, it obtains the third list of child processes under the orphan process recycling process; based on the third list, the first list, and the second list, it determines the list of orphan processes to be identified.

[0096] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

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

[0098] This invention also provides a computer device having the above-described features. Figure 3 The device shown is for process management.

[0099] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 4 As shown, the computer device includes one or more processors 10, memory 20, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a graphical user interface on an external input / output device (such as a display device coupled to the interface). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 4 Take a processor 10 as an example.

[0100] Processor 10 may be a central processing unit, a network processor, or a combination thereof. Processor 10 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0101] The aforementioned memory 20 stores instructions executable by at least one processor 10 to cause the at least one processor 10 to perform the method shown in the above embodiments.

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

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

[0104] The computer device also includes an input device 30 and an output device 40. The processor 10, memory 20, input device 30, and output device 40 can be connected via a bus or other means. Figure 4 Taking the example of a connection between China and Israel via a bus.

[0105] Input device 30 can receive input numerical or character information, and generate key signal inputs related to user settings and function control of the computer device, such as a touchscreen, keypad, mouse, trackpad, touchpad, joystick, one or more mouse buttons, trackball, joystick, etc. Output device 40 may include display devices, auxiliary lighting devices (e.g., light-emitting diodes), and haptic feedback devices (e.g., vibration motors). The aforementioned display devices include, but are not limited to, liquid crystal displays, light-emitting diodes, displays, and plasma displays. In some alternative embodiments, the display device may be a touchscreen.

[0106] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0107] A portion of this invention can be applied as a computer program product, such as computer program instructions, which, when executed by a computer, can invoke or provide the methods and / or technical solutions according to the invention through the operation of the computer. Those skilled in the art will understand that the forms in which computer program instructions exist in a computer-readable medium include, but are not limited to, source files, executable files, installation package files, etc. Correspondingly, the ways in which computer program instructions are executed by a computer include, but are not limited to: the computer directly executing the instructions, or the computer compiling the instructions and then executing the corresponding compiled program, or the computer reading and executing the instructions, or the computer reading and installing the instructions and then executing the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium accessible to a computer.

[0108] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A method for process management, characterized by, The method comprises: If there is a first process that is ended, before changing the parent process of a child process under the first process, obtaining an orphan process recycling process of a 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 recycling 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 recycling process, determining a to-be-identified orphan process list based on the first list and the second list; Based on the end reason identifier, determining whether the first process normally exits, and if the end reason identifier represents that the first process exits abnormally, ending a process in the to-be-identified orphan process list; The determination whether the first process normally exits based on the end reason identifier comprises: if the end reason identifier represents that the first process normally exits, determining whether the orphan process recycling process is in a process white list; and if the orphan process recycling process is not in the process white list, ending the process in the to-be-identified orphan process list. The determination whether the orphan process recycling process is in the process white list if the end reason identifier represents that the first process normally exits comprises: if the orphan process recycling process is in the process white list, sending the to-be-identified orphan process list to a user layer.

2. The method of claim 1, wherein, The method further comprises: Sending the to-be-identified orphan process list to the user layer, and after waiting for a preset time length, traversing the processes in the to-be-identified orphan process list, and determining whether the processes in the to-be-identified orphan process list point to a terminal; If the processes in the to-be-identified orphan process list point to the terminal, ending the processes in the to-be-identified orphan process list.

3. The method according to claim 1 or 2, characterized in that, The method further comprises: Creating a first hook function; If there is a first process that is ended, before changing the parent process of a child process under the first process, based on the first hook function, obtaining an orphan process recycling process of a namespace where the first process is located, an end reason identifier of the first process, a first list of child processes under the orphan process recycling process, and a second list of child processes of the first process.

4. The method according to claim 1 or 2, characterized in that, The method further comprises: Creating a second hook function; Based on the second hook function, obtaining a third list of child processes under the orphan process recycling process, and determining a to-be-identified orphan process list based on the third list, the first list, and the second list.

5. An apparatus for process management, characterized by, The apparatus comprises: A first module configured to, if there is a first process that is ended, before changing the parent process of a child process under the first process, obtain an orphan process recycling process of a 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 recycling process; A second module configured to, after changing the parent process of the child process under the first process, obtain a second list of child processes under the orphan process recycling process, and determine a to-be-identified orphan process list based on the first list and the second list; The third module is configured to determine whether the first process is normally exited based on the end reason identifier, and end the process in the to-be-identified orphan process list if the end reason identifier indicates that the first process is exited abnormally; wherein the determination of whether the first process is normally exited based on the end reason identifier comprises: if the end reason identifier indicates that the first process is normally exited, determining whether the orphan process recycling process is in a process white list; and if the orphan process recycling process is not in the process white list, ending the process in the to-be-identified orphan process list; wherein the determination of whether the orphan process recycling process is in the process white list if the end reason identifier indicates that the first process is normally exited comprises: if the orphan process recycling process is in the process white list, sending the to-be-identified orphan process list to a user layer.

6. A computer device, comprising: The computer readable storage medium has stored thereon computer instructions for causing a computer to perform the method for process management according to any one of claims 1 to 4. The computer readable storage medium has stored thereon computer instructions for causing a computer to perform the method for process management according to any one of claims 1 to 4.

7. A computer readable storage medium characterized in that, The computer readable storage medium has stored thereon computer instructions for causing a computer to perform the method for process management according to any one of claims 1 to 4.

8. A computer program product, characterised in that, The computer readable storage medium has stored thereon computer instructions for causing a computer to perform the method for process management according to any one of claims 1 to 4.

Images