Process monitoring method, computer program product and electronic device

Abstract

The embodiments of the present application provide a process monitoring method, a computer program product, and an electronic device. The method includes: determining a first process; obtaining a file descriptor based on a process identifier of the first process; using the file descriptor to monitor the process status of the first process; when the process status of the first process is a preset state, reading the process information of the first process so that the second process obtains the process information of the first process. The technical solution provided by the embodiments of the present application can solve the problem of process status synchronization between any two processes, and the solution is relatively simple to implement; in addition, the technical solution provided by the embodiments of the present application not only monitors the exit of the process, but also monitors any state of the process, and can also read the process information of the process in each state, which is helpful for the maintenance and management of the system program.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to a process monitoring method, a computer program product, and an electronic device. Background Art

[0002] In the process of computer system development and operation, sometimes the process may exit abnormally or fall into an infinite loop. If there is no corresponding process monitoring mechanism in the system, it is impossible to know the abnormal exit of the process and deal with the abnormality accordingly.

[0003] In the prior art, the parent process can monitor the exit of the child process. When the child process ends or exits abnormally, it will inform the parent process through a specified signal, and the parent process will respond accordingly. However, for a process that is not a child process of its own, when the process exits, it cannot be informed of its exit through the above specified signal. Summary of the invention

[0004] In view of the above problems, the present application provides a process monitoring method, a computer program product and an electronic device, so as to monitor the processes of various relationships.

[0005] In one embodiment of the present application, a process monitoring method is provided. The method comprises:

[0006] Identify the first process;

[0007] Obtaining a file descriptor based on a process identifier of the first process;

[0008] Using the file descriptor, monitoring the process status of the first process;

[0009] When the process state of the first process is a preset state, the process information of the first process is read so that the second process obtains the process information of the first process.

[0010] In another embodiment of the present application, a process monitoring method is provided. The method comprises:

[0011] The second process determines a first process that needs to be monitored for exit, wherein the first process and the second process do not have a parent-child relationship;

[0012] The second process obtains a file descriptor based on a process identifier of the first process;

[0013] The second process uses the file descriptor to monitor the exit event of the first process;

[0014] When the second process monitors the exit event of the first process, it reads the exit information of the first process.

[0015] In another embodiment of the present application, a computer program product is provided, which includes a computer program, and when the computer program is executed by a processor, the processor is enabled to implement the steps in any of the above-mentioned process monitoring methods.

[0016] In another embodiment of the present application, an electronic device is provided, which includes a memory and a processor; the memory is used to store one or more computer instructions, and the one or more computer instructions can implement the steps in any of the above-mentioned process monitoring methods when executed by the processor.

[0017] In order to conveniently illustrate the beneficial effects of the technical solutions provided by the embodiments of the present application, a brief description is first given of the process identifier (or process identity identifier, process ID in English, abbreviated as PID) and the file descriptor based on the process identifier.

[0018] When a process exits, the PID it releases will be reallocated to other new processes after a period of time, which will cause a competition problem (called race-free process signaling). For example, process C originally sent a signal to process A through process A's PID, but process A exited before the signal was sent, and process A's PID was soon reassigned to another process B. At this time, process C will mistakenly send the signal to process B, which will cause process B to exit in serious cases. Different from the implementation of PID, the file descriptor (Pidfd) based on the process identifier can uniquely represent the process regardless of whether the process exits or not.

[0019] In the technical solutions provided by the embodiments of the present application, a file descriptor (Pidfd) based on a process identifier is used to uniquely represent the first process, and the Pidfd of the first process is used to monitor the process status of the first process; at the same time, the present application also adds a read operation to read the process information of the first process when the first process is monitored to be in a preset state, so that the second process obtains the process information of the first process. Among them, the first process and the second process may not have a parent-child relationship, and they may be two independent processes that do not have any relationship. It can be seen that the technical solution provided by the embodiments of the present application can solve the problem of process status synchronization between any two processes, and the solution is relatively simple to implement; in addition, the technical solution provided by the embodiments of the present application not only monitors the exit of the process, but also monitors any state of the process, and can also read the process information of the process in each state, which is helpful for the maintenance and management of the system program. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the following is a brief introduction to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0021] Figure 1 This is a schematic diagram of the principle of a parent process monitoring a child process exit in the prior art;

[0022] Figure 2 For the hypothetical Figure 1 The parent-child process relationship shown in the figure becomes a schematic diagram of a non-parent-child process after hot upgrade;

[0023] Figure 3 A flowchart of a process monitoring method provided in one embodiment of the present application;

[0024] Figure 4 A flowchart of a process monitoring method shown in another form of expression;

[0025] Figure 5 This is a schematic diagram of the file structure files_struct of the process;

[0026] Figure 6 A reference figure used to explain the file descriptor of a process, the file descriptor of a file, and related contents mentioned in the embodiments of the present application;

[0027] Figure 7 A schematic diagram of a process monitoring method provided by another embodiment of the present application;

[0028] Figure 8 A flowchart of a process monitoring method provided in yet another embodiment of the present application;

[0029] Fig. 9 A schematic diagram of the structure of a process monitoring device provided in one embodiment of the present application;

[0030] Fig.10 A schematic diagram of the structure of an electronic device provided in one embodiment of the present application. DETAILED DESCRIPTION

[0031] Figure 1 The schematic diagram shows a parent process monitoring a child process in a parent-child relationship process in the prior art. Figure 1It is shown that the child processes of the parent process include: child process 1, child process 2 and child process 3. In the prior art, the parent process implements asynchronous waiting through the SIGCHLD signal. The principle is: when any process among child process 1, child process 2 and child process 3 exits, the system kernel will send a SIGCHLD signal carrying the process identifier (PID) of the child process to the parent process, and then the parent process will release its resources.

[0032] Assumptions Figure 1 The system program shown in the figure is hot-upgraded. After the hot-upgrade, the parent process (agent) and the three child processes 1, 2 and 3 (container1, container2 and container3) are transformed into a brother relationship instead of a parent-child relationship. Figure 2 If the hot upgrade is required to be compatible with the original functions, that is, the agent can still obtain the process status of container1, container2 and container3, the solution of the prior art through the SIGCHLD signal is no longer applicable.

[0033] The embodiments provided in this application are intended to solve the process state synchronization problem between processes that are not parent-child processes. In order to enable people in the technical field to better understand the solution of this application, the technical solution in the embodiment of this application will be clearly and completely described below in conjunction with the drawings in the embodiment of this application.

[0034] In some processes described in the specification, claims and the above-mentioned figures of the present application, multiple operations appearing in a specific order are included, and these operations may not be executed or executed in parallel in the order in which they appear in this article. The serial numbers of the operations, such as 101, 102, etc., are only used to distinguish different operations, and the serial numbers themselves do not represent any execution order. In addition, these processes may include more or fewer operations, and these operations may be executed in sequence or in parallel. It should be noted that the descriptions of "first", "second", etc. in this article are used to distinguish different messages, devices, modules, etc., do not represent the order of precedence, and do not limit "first" and "second" to different types. In addition, the following embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without making creative work are within the scope of protection of this application.

[0035] Figure 3 and Figure 4 The process flow diagram of the process monitoring method provided by an embodiment of the present application is shown in two ways. Figure 1 and Figure 2 As shown, the method includes:

[0036] 101. Determine the first process;

[0037] 102. Obtain a file descriptor based on a process identifier of the first process;

[0038] 103. Using the file descriptor, monitor the process status of the first process;

[0039] 104. When the process state of the first process is a preset state, read the process information of the first process so that the second process obtains the process information of the first process.

[0040] In specific implementation, the above 101 can determine the process to be monitored based on the received monitoring task, that is, the first process mentioned above. Or, in the hot upgrade scenario, the parent process of the first process is replaced by the second process due to hot upgrade. At this time, the process to be monitored can be determined based on the replaced parent process. That is, this step 101 "determining the first process" can specifically include:

[0041] Based on the received monitoring task, determining the first process to be monitored specified by the monitoring task; or

[0042] The first process is determined to be a process to be monitored through the parent process of the first process, wherein the second process replaces the parent process through system hot upgrade but has no parent-child relationship with the first process.

[0043] In addition, the first process and the second process in this embodiment may be brother processes, or the first process and the second process may not be in a parent-child process relationship.

[0044] The monitoring task may be pre-written in the program, and after the program is loaded into the memory, the corresponding process, such as the second process in this embodiment, may request the monitoring task from the kernel.

[0045] In the above 102, the file descriptor (Pidfd) based on the process identifier is essentially a file descriptor. In this embodiment, Pidfd uses a file descriptor (file descriptor, fd) to represent an existing process. In the life cycle of a Pidfd, it will only represent one process, so when using Pidfd to send a signal to a target process, there is no need to worry about sending it to another process by mistake.

[0046] In an achievable technical solution, step 102 of "obtaining a file descriptor based on a process identifier of the first process" in this embodiment may include the following steps:

[0047] 1021. Create a file structure for the first process;

[0048] 1022. Obtain a process descriptor pointer of the first process according to the process identifier of the first process;

[0049] 1023. Place the process descriptor pointer in the file structure;

[0050] 1024. Determine the file descriptor according to the file descriptor table of the first process; wherein the pointer of the file structure is located as a table entry in the file descriptor table.

[0051] In a specific application scenario, Linux (full name GNU / Linux) is a type of Unix operating system. The design concept of Linux is that everything is a file, the network is a file, and peripherals such as keyboards are also files. Therefore, all resources have a unified interface. Developers can transfer data through the network like writing files, and can also see the resource usage of the process through the / proc / file. The Linux kernel assigns a file descriptor fd to each accessed file. Simply put, each opened or newly created file corresponds to a file descriptor; the file descriptor is represented by a file structure in the kernel. The process has a file descriptor, and the file opened by the process has a file descriptor. When Linux is implemented, the file descriptor of this process is actually an index value, pointing to a record table of files opened by each process. Figure 5 The figure shows an example in which the file descriptor of a process is represented as a file structure files_struct in the kernel, which contains pointers corresponding to multiple files opened by the process. The index values ​​corresponding to the pointers of each file in the file structure files_struct (such as the numbers 0, 1, 2, 3, ... in the figure) constitute the file descriptor of the process.

[0052] It should be noted here that: Figure 6 In the example shown, the file descriptor of process 1 (i.e., files_struct1) contains pointers corresponding to the file descriptors (i.e., file_struct) of multiple files opened by the process. Figure 6 The file_struct1 in the file contains the directory structure (f_dentry) of file a, such as / ** / && / a; this makes it easy to read file a based on the directory structure.

[0053] In addition, a program can be understood as a file on the hard disk; a process is a file loaded into the memory. In addition to the file loaded into the memory, it also has a structure for all file description information. The structure that describes the process is called a PCB (process control block). In each PCB, there is a file descriptor table, which points to files_struct (system open file table) through the index values ​​corresponding to the multiple files opened by the process in the file descriptor table. The file descriptor of a process is formally a non-negative integer, which is an index value that points to the record table of open files of the process maintained by the kernel for each process. In addition, in the file descriptor table of a process (which is represented by a file structure in the kernel), the pointers corresponding to index values ​​0, 1, and 2 in the file descriptor table point to a read input file file[0], an output write file file[1], and an error message write file file[2] respectively.

[0054] See also Figure 6 In the example shown, when process 1 (process1) calls open to open a file or creates a new file, the kernel will assign a file descriptor fd to the newly opened file or the newly created file, and the file descriptor of the newly opened file or the newly created file (represented by the file structure in the kernel, that is, Figure 6 The pointer corresponding to file_struct1 in process 1 is added to the file descriptor of process 1 (which is also represented by a file structure in the kernel). The above process can be represented as the following code:

[0055] fd=open(“ / ** / && / a”,O_RDONLY)

[0056] Among them, O_RDONLY is a file flag. In addition to O_RDONLY, file flags may also include but are not limited to: O_NONBLOCK, O_WRONLY and O_SYNC. File flags are used to specify the way to open a file. For example, Figure 6 In the figure, process 2 opens file a in directory / ** / && / ; process 3 opens file b in directory / ** / && / . It can be seen that both process 1 and process 2 open the same file a, but the opening method and read and write location are different. Figure 6 The values ​​of f_op in file_struct1 and file_struct2 are different. The value of f_op represents the current read and write position of each process.

[0057] The file structure corresponding to each opened file in the kernel points to a file_operations structure. The members of this structure are all function pointers, pointing to kernel functions that implement various file operations. For example, when reading a file descriptor in the program, read enters the kernel through a system call, and then finds the file structure pointed to by the file descriptor, finds the file_operations structure pointed to by the file structure, and calls the kernel function pointed to by its read member (for example, the implementation function in the kernel code may be sys_read()) to complete the user request. In the user program, functions such as lseek, read, write, ioctl, and open are called, and ultimately the kernel calls the kernel functions pointed to by the members of file_operations to complete the user request.

[0058] The release member in the file_operations structure is used to complete the close request of the user program. It is called release instead of close because it does not necessarily close the file, but reduces the reference count. The file is closed only when the reference count is reduced to 0.

[0059] In addition, Figure 6 In the example shown, each file structure has a pointer to a dentry structure. "Dentry" is the abbreviation of directory entry. The parameter passed to the open, stat and other functions is a path, such as / ** / && / a. The inode of the file needs to be found according to the path. In order to reduce the number of disk reads, the kernel caches the tree structure of the directory, called the dentry cache, in which each node is a dentry structure. You only need to search along the dentry of each part of the path. Find the ** directory from the root directory, then find the && directory, and then find the file a.

[0060] The dentry cache only stores the most recently accessed directory entries. If the directory entry you are looking for is not in the cache, it must be read from the disk into the memory. Each dentry structure has a pointer to the inode structure. The inode structure stores the information read from the disk inode.

[0061] The above briefly introduces the file descriptor of the file, the file descriptor of the process and their related contents. Based on the foreshadowing of the above content, the following introduces the process identifier-based file descriptor (Pidfd) of the process in the embodiment of the present application. The essence of Pidfd is a file descriptor, which is similar to the file descriptor of the file mentioned above, and corresponds to a file structure, and the file structure corresponds to a node (inode) structure. The kernel also defines a pidfd_fops for the file structure as its exclusive file_operations, which provides the file associated with the file structure with its exclusive file behavior.

[0062] Furthermore, Pidfd does not have a corresponding actual visible file path (denty) in form, but is implemented using anon_inode (anonymous node). That is, the file structure in the above step 1021 in this embodiment may include: a first pointer pointing to a node structure and a second pointer pointing to a file operation structure. Accordingly, the method provided in this embodiment may also include the following steps:

[0063] An anonymous node method is adopted to create a node structure corresponding to the first pointer, so that the file corresponding to the structure has no visible file path.

[0064] Having the node structure, file structure and file_operations is not enough. The pidfd must be associated with the process information to achieve the design goal of pidfd. This is achieved through the file private member file->private_data. In specific implementation, pidfd can be created through the clone() function or the proprietary open() function. In this creation process, the PID of the process will be directly or indirectly passed in, and then in the creation process, the Linux kernel will call the function get_pid(struct pid*pid) to convert the PID into a process descriptor pointer, and store the process descriptor pointer of the process in the file->private_data member.

[0065] Among them, get_pid(struct pid*pid) returns the process descriptor pointer.

[0066] The above-mentioned proprietary open() function refers to the Pidfd_open() function, and the function of the Pidfd_open() function is to obtain the file descriptor (i.e., the file structure) pointing to the process. The Pidfd_open() function generates a file identifier corresponding to a process identifier, and the Pidfd_open() function needs to be implemented through the system call syscall. That is, the above-mentioned steps 1021 to 1024 of this embodiment can be implemented by calling the Pidfd_open() function.

[0067] During the process creation process corresponding to the Pidfd_open() function, the get_pid() function will be called to obtain the process descriptor pointer. That is, the above step 1022 "According to the process identifier of the first process, obtain the process descriptor pointer of the first process" can be specifically as follows: through the process identifier of the first process, call the get_pid() function to obtain the process descriptor pointer of the first process. More specifically, the above step 1023 "Put the process descriptor pointer in the file structure" can be specifically as follows: put the process descriptor pointer in a private member in the file structure. In essence, this step is also executed by the process corresponding to the Pidfd_open() function, and the process descriptor pointer returned by the get_pid() function is placed in the private member of the file descriptor based on the process identifier of the created first process (that is, the corresponding kernel representation is a file structure).

[0068] Based on a specific achievable technical solution of step 102 above, in step 104 of this embodiment, “reading the process information of the first process so that the second process obtains the process information of the first process” may accordingly include the following steps:

[0069] 1041. Obtain a process descriptor pointer of the first process according to the file descriptor of the first process;

[0070] 1042. Locate the process descriptor of the first process according to the process descriptor pointer of the first process;

[0071] 1043. Read process information of the first process from the process descriptor of the first process.

[0072] In Linux, each process has a process descriptor, which is a structure called task_struct. Task_struct stores a lot of information about process control. task_struct is a data structure in the Linux kernel that is loaded into RAM and contains information about the process. Each process stores its information in the task_struct data structure.

[0073] For example, the task_struct content of a process may include but is not limited to the following:

[0074] Identifier: A unique identifier that describes this process and is used to distinguish other processes;

[0075] Status: task status, exit code, exit signal, etc.;

[0076] Priority: The priority relative to other processes;

[0077] Program counter: the address of the next instruction to be executed in the program;

[0078] Memory pointers: include pointers to program code and process-related data, as well as pointers to memory blocks shared with other processes.

[0079] Context data: data in the processor's registers when the process is executing;

[0080] I / O status information: including displayed I / O requests, I / O devices assigned to the process, and a list of files being used by the process;

[0081] Accounting information: may include total processor time, total number of clocks used, time limits, accounting accounts, etc.

[0082] Based on the above discussion, it can be known that the process identifier-based file descriptor Pidfd of the first process (expressed as a file structure in the kernel) contains the process identifier PID of the first process. Therefore, this embodiment can obtain the process descriptor pointer of the first process based on the Pidfd of the first process; then the process descriptor can be located according to the process descriptor pointer, and then the process information of the first process can be read from the process descriptor.

[0083] In the above 103 and 104, the process state of the first process may include: exit state, interruptible state (or sleeping state), uninterruptible state, running state, etc. The preset state may be one of the above states; more specifically, the preset state may be an exit state. Accordingly, the process information of the first process read is exit information, such as an exit code in a process descriptor.

[0084] In an achievable solution, the above step 103 of "using the file descriptor to monitor the process status of the first process" may be specifically as follows:

[0085] The file descriptor is placed in a monitoring list so that the monitoring thread monitors the process status corresponding to the first process corresponding to the file descriptor in the list.

[0086] Furthermore, this embodiment may also include the following steps:

[0087] 105. Configure the preset state for the first process, so that the listening thread triggers the reading operation when it monitors that the first process is in the preset state.

[0088] Taking the exit status as an example, the po11() function can be used to monitor the exit status of the process, such as the EPOLLIN event. In specific implementation, the preset status can be configured through the following structure.

[0089]

[0090] Before the scheme provided by the embodiment of the present application is proposed, if there is no parent-child process relationship, a process cannot monitor the process state of another process. The technical scheme provided by the embodiment of the present application fills this gap. With the file descriptor Pidfd based on the process identifier, the kernel can easily monitor the state of any process, and the Linux kernel does implement poll in the pidfd file operation function pidfd_fops, i.e. pidfd_poll().

[0091] Although poll() can be used to monitor process status, such as getting notification when a process exits, it is still not enough for a process management system. It is also necessary to be able to specify waiting for these target processes to exit and obtain corresponding status information (such as exit information) after exiting.

[0092] The technical solution provided in the embodiment of the present application expands the pidfd mechanism to solve the demand for non-child process exit status monitoring. That is, a reading mechanism is added to read the process information of the first process when it is known that the first process is in a preset state. More specifically, after it is known that the first process has exited, the exit information of the first process is read to facilitate the second process to make a corresponding response. It should be noted here that: this embodiment adopts a reading mechanism, and in fact, after monitoring that the process is in a preset state, the process information (such as exit information) can also be obtained by extending wait_pid. This article does not elaborate on how to extend wait_pid, and can refer to relevant materials.

[0093] Combine the following Figure 7 The flowchart shown in the figure illustrates the method embodiment provided by the present application. Figure 7 As shown, the method includes:

[0094] S1. Determine whether there is a target process that needs to be monitored. If yes, proceed to step S2; if no, complete.

[0095] S2. Call the Pidfd_open() function through the process ID of the target process to obtain the Pidfd of the target process.

[0096] Figure 7 FIG. 4 shows a scenario in which two target processes need to be monitored, and the Pidfds of the two target processes are Pidfd1 and Pidfd2 respectively. Pidfd1 and Pidfd2 are added to the monitoring list.

[0097] S3. Start a monitoring thread to monitor the process status of the target process corresponding to each Pidfd in the list.

[0098] See also Figure 7 In the example shown in , the monitoring thread calls the poll() function to monitor the process status of each target process. If it is detected that the target process corresponding to Pidfd1 has exited (that is, it is in the exit state), the monitoring thread will receive EPOLLINevent (exit event).

[0099] S4. Assuming that an exit event of the target process corresponding to Pidfd1 is received, based on Pidfd1, the exit information (exit status) of the target process corresponding to Pidfd1 is read.

[0100] After reading, you can continue to monitor the process status of other target processes.

[0101] Figure 8 FIG. 2 is a flow chart of a process monitoring method provided by another embodiment of the present application. This embodiment mainly focuses on monitoring process exit events. Figure 8 As shown, the method includes:

[0102] 201. Determine the first process that needs to be monitored for exit;

[0103] 202. Obtain a file descriptor based on a process identifier of the first process;

[0104] 203. Using the file descriptor, monitor an exit event of the first process;

[0105] 204. When an exit event of the first process is monitored, read exit information of the first process.

[0106] In a specific implementation, the first process and the second process may be two independent processes that have no relationship with each other, but due to certain functional requirements, the second process needs to obtain the exit information of the first process.

[0107] Furthermore, the above step 203 "using the file descriptor to monitor the exit event of the first process" includes:

[0108] 2031. Write the file descriptor into the monitoring list;

[0109] 2032. Start a listening thread so that the listening thread listens to an exit event corresponding to the first process corresponding to the file descriptor in the list.

[0110] Furthermore, in the above step 204, “when the exit event of the first process is monitored, reading the exit information of the first process” includes:

[0111] 2041. When an exit event of the first process is monitored, obtaining a process descriptor pointer of the first process according to a file descriptor of the first process;

[0112] 2042. Locate the process descriptor of the first process according to the process descriptor pointer of the first process;

[0113] 2043. Read process information of the first process from the process descriptor of the first process.

[0114] It should be added that: this embodiment is only for monitoring the process exit event, and after the process state in the above method embodiment is replaced with the exit state, it is the solution provided by this embodiment. Therefore, a more detailed description of each step in the method provided by this embodiment can be found in the above description, and will not be repeated here.

[0115] Fig. 9 A schematic diagram of the structure of a process monitoring device provided by an embodiment of the present application is shown. As shown in the figure, the process monitoring device includes: a determination module 11, an acquisition module 12, a monitoring module 13 and a reading module 14. Among them, the determination module 11 is used to determine a first process. The acquisition module 12 is used to obtain a file descriptor based on a process identifier of the first process. The monitoring module 13 is used to monitor the process state of the first process using the file descriptor. The reading module 14 is used to read the process information of the first process when the process state of the first process is a preset state, so that the second process obtains the process information of the first process.

[0116] Furthermore, when acquiring the file descriptor based on the process identifier of the first process, the acquisition module 12 is specifically used to:

[0117] Create a file structure for the first process; obtain a process descriptor pointer of the first process according to the process identifier of the first process; place the process descriptor pointer in the file structure; determine the file descriptor according to the file descriptor table of the first process; wherein the pointer of the file structure is located as a table entry in the file descriptor table.

[0118] Furthermore, the file includes: a first pointer pointing to a node structure and a second pointer pointing to a file operation structure. Accordingly, the device provided in the embodiment of the present application may also include a creation module. The creation module is used to create a node structure corresponding to the first pointer in an anonymous node manner, so that the file does not have a visible file path.

[0119] Furthermore, when the reading module 14 reads the process information of the first process so that the second process obtains the process information of the first process, it is specifically used to:

[0120] According to the file descriptor of the first process, a process descriptor pointer of the first process is obtained; according to the process descriptor pointer of the first process, the process descriptor of the first process is located; and process information of the first process is read from the process descriptor of the first process.

[0121] More specifically, the preset state in this embodiment may be the exit state of the first process, and correspondingly, the process information of the first process read is the exit information.

[0122] Furthermore, when the monitoring module 13 uses the file descriptor to monitor the process status of the first process, it is specifically used to:

[0123] The file descriptor is placed in a monitoring list so that the monitoring thread monitors the process status corresponding to the first process corresponding to the file descriptor in the list.

[0124] Furthermore, the apparatus described in this embodiment may further include a configuration module. The configuration module is used to configure the preset state for the first process, so that the monitoring thread triggers the reading operation when monitoring that the first process is in the preset state.

[0125] Specifically, in this embodiment, the first process and the second process are brother processes, or the first process and the second process are not in a parent-child process relationship.

[0126] Furthermore, in the apparatus described in this embodiment, when determining the first process, the determining module 11 is specifically configured to:

[0127] Based on the received monitoring task, determining the first process to be monitored specified by the monitoring task; or

[0128] The first process is determined to be a process to be monitored through the parent process of the first process, wherein the second process replaces the parent process through system hot upgrade but has no parent-child relationship with the first process.

[0129] The present application also provides another embodiment of a process monitoring device. The structure of the device in this embodiment is the same as above. Fig. 9 . This embodiment is proposed for the process exit scenario. Specifically, the process monitoring device includes: a determination module, an acquisition module, a monitoring module and a reading module. Among them, the determination module is used to determine the first process that needs to be exited. The acquisition module is used to obtain the file descriptor of the first process based on the process identifier. The monitoring module is used to use the file descriptor to monitor the exit event of the first process. The reading module is used to read the exit information of the first process when the exit event of the first process is monitored, so that the second process obtains the exit information of the first process.

[0130] Furthermore, when the monitoring module uses the file descriptor to monitor the exit event of the first process, it is specifically used to:

[0131] The file descriptor is written into a monitoring list; and a monitoring thread is started so that the monitoring thread monitors an exit event corresponding to the first process corresponding to the file descriptor in the list.

[0132] Further, when the reading module monitors the exit event of the first process, it reads the exit information of the first process, specifically for:

[0133] When the exit event of the first process is monitored, the file descriptor table of the first process is obtained according to the file descriptor of the first process; the process descriptor of the first process is located according to the process descriptor pointer included in the file descriptor table of the first process; and the process information of the first process is read from the process descriptor of the first process.

[0134] Fig.10 FIG. 1 is a schematic diagram showing the structure of an electronic device provided by an embodiment of the present application. Fig.10 As shown, the electronic device includes a memory 21 and a processor 22; the memory 21 is used to store one or more computer instructions, and the one or more computer instructions can implement the following steps when executed by the processor 22:

[0135] Identify the first process;

[0136] Obtaining a file descriptor based on a process identifier of the first process;

[0137] Using the file descriptor, monitoring the process status of the first process;

[0138] When the process state of the first process is a preset state, the process information of the first process is read so that the second process obtains the process information of the first process.

[0139] Positioning is performed according to the environment image and the partial data.

[0140] The memory 21 may be configured to store various other data to support operations on the electronic device. Examples of such data include instructions for any application or method for operating on the electronic device. The memory 21 may be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as a static random access memory (SRAM), an electrically erasable programmable read-only memory (EEPROM), an erasable programmable read-only memory (EPROM), a programmable read-only memory (PROM), a read-only memory (ROM), a magnetic memory, a flash memory, a magnetic disk or an optical disk.

[0141] When the processor 22 executes the program in the memory 21, in addition to the above functions, it can also realize other functions, and the details can be referred to the description of the above embodiments.

[0142] Further, if Fig.10 As shown, the electronic device also includes: a communication component 23, a display 24, a power component 25, an audio component 26 and other components. Fig.10 Only some components are shown schematically, which does not mean that the electronic device only includes Fig.10 Components shown.

[0143] Another embodiment of the present application provides an electronic device, the structure of which is similar to the above Fig.10 Similarly, the electronic device includes a memory and a processor; the memory is used to store one or more computer instructions, and the one or more computer instructions can implement the following steps when executed by the processor:

[0144] Identify the first processes for which exit monitoring is required;

[0145] Obtaining a file descriptor based on a process identifier of the first process;

[0146] Using the file descriptor, monitoring the exit event of the first process;

[0147] When the exit event of the first process is monitored, the exit information of the first process is read so that the second process obtains the exit information of the first process.

[0148] When executing the program in the memory, the processor may realize other functions in addition to the above functions. For details, please refer to the description of the above embodiments.

[0149] Accordingly, an embodiment of the present application further provides a computer-readable storage medium storing a computer program, and when the computer program is executed by a computer, the steps or functions of the methods provided in the above embodiments can be implemented.

[0150] Furthermore, an embodiment of the present application also provides a computer program product, including a computer program, which, when executed by a processor, enables the processor to implement the steps or functions of the methods provided in the above embodiments.

[0151] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components displayed as units may or may not be physical units, that is, they may be located in one place, or they may be distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the scheme of this embodiment. Ordinary technicians in this field can understand and implement it without paying creative labor.

[0152] Through the description of the above implementation modes, those skilled in the art can clearly understand that each implementation mode can be implemented by means of software plus a necessary general hardware platform, and of course, can also be implemented by hardware. Based on such an understanding, the above technical solution is essentially or the part that contributes to the prior art can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0153] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the embodiments of the present application.

Claims

1. A process monitoring method, comprising: Identify the first process; Obtaining a file descriptor based on a process identifier of the first process, comprising: creating a file structure for the first process; obtaining a process descriptor pointer of the first process according to the process identifier of the first process; placing the process descriptor pointer in the file structure; determining the file descriptor according to a file descriptor table of the first process; wherein the pointer of the file structure is located as a table entry in the file descriptor table; Using the file descriptor, monitoring the process status of the first process; When the process state of the first process is a preset state, the process descriptor pointer of the first process is obtained according to the file descriptor of the first process, the process descriptor of the first process is located according to the process descriptor pointer, and the process information of the first process is read from the process descriptor of the first process so that the second process obtains the process information of the first process.

2. The method according to claim 1, wherein: The file structure includes: a first pointer pointing to a node structure and a second pointer pointing to a file operation structure; and The method further comprises: An anonymous node method is adopted to create a node structure corresponding to the first pointer, so that the file corresponding to the file structure has no visible file path.

3. According to the method of claim 1, the preset state is the exit state of the first process, and correspondingly, the process information of the first process read is the exit information.

4. The method according to claim 1 or 2, using the file descriptor to monitor the process status of the first process, comprising: The file descriptor is placed in a monitoring list so that the monitoring thread monitors the process status corresponding to the first process corresponding to the file descriptor in the list.

5. The method according to claim 4, further comprising: The preset state is configured for the first process so that the listening thread triggers the reading operation when it monitors that the first process is in the preset state.

6. The method according to claim 1 or 2, wherein the first process and the second process are brother processes, or the first process and the second process are not in a parent-child process relationship.

7. The method according to claim 6, determining the first process comprises: Based on the received monitoring task, determining the first process to be monitored specified by the monitoring task; or The first process is determined to be a process to be monitored through the parent process of the first process, wherein the second process replaces the parent process through system hot upgrade but has no parent-child relationship with the first process.

8. A process monitoring method, comprising: Identify the first processes for which exit monitoring is required; Obtaining a file descriptor based on a process identifier of the first process, comprising: creating a file structure for the first process; obtaining a process descriptor pointer of the first process according to the process identifier of the first process; placing the process descriptor pointer in the file structure; determining the file descriptor according to a file descriptor table of the first process; wherein the pointer of the file structure is located as a table entry in the file descriptor table; Using the file descriptor, monitoring the exit event of the first process; When the exit event of the first process is monitored, the process descriptor pointer of the first process is obtained according to the file descriptor of the first process, the process descriptor of the first process is located according to the process descriptor pointer of the first process, and the process information of the first process is read from the process descriptor of the first process so that the second process obtains the exit information of the first process.

9. The method according to claim 8, using the file descriptor to monitor the exit event of the first process, comprising: Write the file descriptor into the monitoring list; A listening thread is started so that the listening thread listens to an exit event corresponding to the first process corresponding to the file descriptor in the list.

10. A computer program product, comprising a computer program, which, when executed by a processor, enables the processor to implement the steps of the method according to any one of claims 1 to 7, or the steps of the method according to claim 8 or 9.

11. An electronic device comprising a memory and a processor; the memory is used to store one or more computer instructions, and when the one or more computer instructions are executed by the processor, they can implement the steps in the method described in any one of claims 1 to 7, or implement the steps in the method described in claim 8 or 9.

Images