Log recording method and device for shutdown and restart operations of a linux system

Abstract

The application discloses a kind of linux system shutdown, log recording method and device of reboot operation. Method includes: in user mode, the operation of triggering loading kernel module is detected, network parameter containing IP address is passed to kernel;Kernel receives and stores network parameter to memory;When detecting system call of reboot, enter kernel and execute the following log recording operation: collect the log information of kernel space, the log information of this kernel space includes the information of the parent-child relationship tree of shell process in current system;According to the information generated by collection, log;IP address in network parameter is read from memory, and log is sent to the recording device corresponding to IP address by network.The beneficial effects of the present application include: ①can obtain the log information of kernel space, information is more comprehensive;②log can be sent to the recording device corresponding to the IP address by network, without the support of specific hardware, and pstore storage resources will not be consumed.

Description

Technical Field

[0001] This application relates to the field of data processing technology, specifically to a method and apparatus for logging Linux system shutdown and restart operations. Background Technology

[0002] Operating system installation is crucial, and power operations are even more sensitive. For Linux systems, reboot, poweroff (which supports scheduled shutdowns or restarts), and shutdown (which directly cuts off power) are particularly important. Although common Linux distributions restrict access to these three operations for ordinary users at the permission level, this restriction is far from sufficient for root (super administrator) users or users in the root group. Therefore, it is extremely important to record detailed information related to these three power operations.

[0003] These three types of operations are simply a piece of code within the system. Any process and any user has the right to execute this code, provided they have the necessary permissions. Currently, the following are some common solutions for comprehensively recording the process and user information that executes this sensitive code.

[0004] Option 1: Last login method.

[0005] `last` is a Linux utility that reads the file named `wtmp` located in the ` / var / log / ` directory (the log file storage directory). This file records user logins and logouts, as well as system startup and shutdown information, and displays all the login information recorded in that file. If the `-x` parameter is included, it will further display information such as system shutdowns, reboots, and changes in runlevels.

[0006] Option 2: systemd (system and services manager) method.

[0007] systemd is a centralized system and configuration management program (init) within Linux systems, including daemons, libraries, and application software. Modern Linux distributions like Red Hat and Debian integrate systemd tools. The shutdown and reboot operations are actually code within systemd. This can be seen by examining the link information of the reboot, shutdown, and poweroff commands, which are all symbolic links to systemctl (system control, a command-line tool used to manage systemd). Since it's code within systemd, modifications can be made before and after this code segment to obtain detailed information about these three types of operations.

[0008] The `last` method in Solution 1 is essentially implemented in the same way. The files in the ` / var / log / ` directory that `last` reads are the records kept by systemd. `last` is only responsible for parsing and displaying them.

[0009] Option 3: pstore (persistent storage) method.

[0010] pstore is primarily used to store log information from kernel exceptions (and can also store system shutdowns and reboots). It works by managing a non-volatile storage space. When a system exception occurs, the log information is written to the storage space managed by pstore, and then read back and provided to the user as a file when the system returns to normal.

[0011] However, each of the three methods mentioned above has its own drawbacks.

[0012] Solution 1 and Solution 2 work on the same principle: they use systemd to record detailed information about shutdown and reboot operations to a file before performing the actual shutdown. However, Linux isolates processes in user space and kernel space, so more detailed information cannot be obtained from systemd. For example, these two solutions can only determine the time of system shutdown, but not which process triggered the shutdown operation. This incomplete information is a drawback of the first two solutions.

[0013] For Option 3, in modern Linux systems, executing shutdown or reboot operations via command line first enters the systemd code, triggering the following two operations: 1. Shutting down all services; 2. Unmounting the file system. Then, it enters the kernel and executes the reboot system call, performing the actual kernel shutdown or reboot operations. Once in kernel space, processes are no longer restricted by user space and can access more process information, including the process parent-child relationship tree. Since the file system is no longer available, log data can be stored in the pstore. However, this option relies on specific hardware support and consumes valuable pstore storage resources. While pstore can be programmed to store shutdown and reboot information, it is more reasonable to use it for storing system exception logs. Summary of the Invention

[0014] This application provides a method and apparatus for logging Linux system shutdown and restart operations.

[0015] Firstly, this application provides a method for logging Linux system shutdown and restart operations, including:

[0016] When a user-space operation to load a kernel module is detected, network parameters containing the IP address are passed to the kernel.

[0017] The kernel receives and stores the network parameters in memory;

[0018] When a system reboot call is detected, the kernel is entered to perform the following logging operations: collect log information in the kernel space, which includes information about the parent-child relationship tree of the shell processes in the current system; generate logs based on the collected information; read the IP address from the network parameters in memory, and send the logs over the network to the recording device corresponding to the IP address.

[0019] In some alternative implementations, before entering the kernel to perform the following logging operations, the method further includes: entering user mode to perform the following log writing operations: collecting log information from user space and writing it into memory.

[0020] In some optional implementations, the step of entering the kernel to perform the following logging operation further includes: obtaining the log information of the user space from memory; and the step of generating logs based on the collected information includes: concatenating the log information of the kernel space and the log information of the user space to generate logs.

[0021] In some optional implementations, before entering the kernel to perform the following logging operations, the method further includes: obtaining the parameters of the reboot system call; determining, based on the correspondence of events in the parameters, whether the reboot or shutdown operation was triggered by a user via a command line, or whether the reboot system call was executed by another process; if it is determined that the reboot or shutdown operation was triggered by a user via a command line, then the step of entering user mode to perform the following log writing operation is executed; if it is determined that the reboot system call was executed by another process, then the step of entering the kernel to perform the following logging operation is executed.

[0022] In some alternative implementations, after entering the kernel and performing the following logging operation, the method further includes: after the log is sent, performing the shutdown and restart operation indicated by the restart system call.

[0023] In some optional implementations, the step of entering user space to perform the following log writing operations further includes: after collecting log information from user space and writing it to memory, performing operations to shut down the service and unmount the file system.

[0024] Secondly, this application provides a logging device for Linux system shutdown and restart operations, comprising:

[0025] The user-mode execution module is configured to pass network parameters, including the IP address, to the kernel when the user-mode detects an operation that triggers the loading of a kernel module.

[0026] The kernel-mode execution module is configured to enable the kernel to receive and store the network parameters in memory; and, upon detecting a reboot system call, to enter the kernel and perform the following logging operations: collect log information in the kernel space, which includes information about the parent-child relationship tree of the shell processes in the current system; generate logs based on the collected information; read the IP address from the network parameters from memory, and send the logs over the network to the recording device corresponding to the IP address.

[0027] In some optional implementations, the user-mode execution module is further configured to enter user mode and perform the following log writing operation before entering the kernel to perform the following logging operation: collect log information from user space and write it to memory.

[0028] In some optional implementations, the kernel-mode execution module is further configured to obtain the user-space log information from memory; and the step of generating logs based on the collected information includes: concatenating the kernel-space log information and the user-space log information to generate logs.

[0029] In some optional implementations, the device further includes a kernel-mode determination module; the kernel-mode determination module is configured to obtain the parameters of the restart system call, and determine, based on the correspondence of events in the parameters, whether the restart or shutdown operation was triggered by a user via command line, or whether the restart system call was executed by another process; if it is determined that the restart or shutdown operation was triggered by a user via command line, then the step of entering user mode to perform the following log writing operation is executed; if it is determined that the restart system call was executed by another process, then the step of entering kernel mode to perform the following log recording operation is executed.

[0030] In some optional implementations, the kernel-mode execution module is further configured to execute the shutdown and restart operations indicated by the restart system call after the log is sent.

[0031] In some optional implementations, the user-space execution module is further configured to perform operations to shut down the service and unload the file system after collecting user-space log information and writing it into memory.

[0032] Thirdly, this application provides a computer device, including: one or more processors; and a storage device having one or more programs stored thereon, which, when executed by the one or more processors, cause the one or more processors to perform the method as described in the first aspect.

[0033] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by one or more processors, implements the method described in the first aspect.

[0034] To address the issues of incomplete information retrieval in existing last and systemd methods, and the reliance on specific hardware and resource consumption of pstore (persistent storage) methods, this application proposes a method and apparatus for logging Linux system shutdown and reboot operations. The beneficial effects achieved by adopting the above technical solution include, but are not limited to:

[0035] ① By performing customized operations in the kernel, log information in the kernel space can be obtained, including but not limited to information about the parent-child relationship tree of the shell process, thus obtaining more comprehensive log information.

[0036] ② By triggering the kernel module loading operation in user space, network parameters containing the IP address are passed to the kernel, enabling the kernel to send the collected logs to the recording device corresponding to the IP address over the network. The recording device is a general-purpose device, so no specific hardware support is required and it does not consume valuable pstore storage resources. Attached Figure Description

[0037] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings. The drawings are for illustrative purposes only and are not intended to limit the invention. In the drawings:

[0038] Figure 1 This is a schematic diagram of an exemplary system architecture of at least one embodiment of this application;

[0039] Figure 2 This is a timing flowchart of a Linux system shutdown and restart operation logging method according to an embodiment of this application;

[0040] Figure 3 This is a block diagram illustrating the working principle of a logging method for Linux system shutdown and restart operations according to an embodiment of this application;

[0041] Figure 4 This is a block diagram illustrating the working principle of a logging method for Linux system shutdown and restart operations according to another embodiment of this application;

[0042] Figure 5 This is a schematic diagram of a log recording device for Linux system shutdown and restart operations according to an embodiment of this application;

[0043] Figure 6 This is a schematic diagram of the hardware configuration of a computer device according to an embodiment of this application. Detailed Implementation

[0044] In order to gain a more detailed understanding of the features and technical content of the embodiments of this application, the implementation of the embodiments of this application will be described in detail below with reference to the accompanying drawings. The accompanying drawings are for reference and illustration only and are not intended to limit the embodiments of this application.

[0045] refer to Figure 1 , Figure 1 An exemplary system architecture 100 is shown for a method and apparatus for logging shutdown and restart operations of a Linux system according to at least one embodiment of this application.

[0046] like Figure 1As shown, the system architecture 100 may include at least one recording device 101, a server 102, and a network 103. The network 103 serves as a medium for providing a communication link between the recording device 101 and the server 102. The network 103 may include various connection types, such as wired or wireless communication links, or fiber optic cables, etc. Users can use the recording device 101 to interact with the server 102 via the network 103 to receive or send messages, etc.

[0047] The recording device 101 can be hardware, specifically various electronic devices with memory. The server 102 can be hardware, specifically a server deployed with a Linux-like system. The server 102 can be implemented as a distributed server cluster composed of multiple servers, or as a single server. No specific limitation is made here.

[0048] It should be noted that the logging method for Linux system shutdown and restart operations provided in this application is generally executed by server 102, and correspondingly, the logging device for Linux system shutdown and restart operations is generally set in server 102.

[0049] It should be understood that Figure 1 The number of terminal devices, networks, and servers shown is merely illustrative. Depending on implementation needs, any number of terminal devices, networks, and servers can be included.

[0050] refer to Figure 2 , Figure 2 This is a timing flowchart illustrating a method for logging Linux system shutdown and restart operations according to an embodiment of this application. The method for logging Linux system shutdown and restart operations according to this application can be performed by, for example... Figure 1 The system architecture shown is implemented in server 102.

[0051] like Figure 2 As shown, the Linux system shutdown and restart logging method of this application may include the following steps:

[0052] Step 21: When the user space detects the operation of loading the kernel module, the network parameters containing the IP address are passed to the kernel through the kernel module; the kernel receives and stores the network parameters in memory.

[0053] Step 22: A reboot system call (i.e., a system restart call) is detected;

[0054] Step 25: Enter the kernel. When executing the reboot system call, the following customized operations are performed first, namely kernel-mode logging operations: collect log information in the kernel space, which includes information about the parent-child relationship tree of the shell processes in the current system; generate logs based on the collected information; read the IP address from the network parameters in memory and send the logs over the network to the recording device corresponding to the IP address.

[0055] In some optional steps, prior to step 25, the method may further include:

[0056] Step 24: Enter user space and perform the following customized operation, namely the user space log writing operation: collect log information from user space and write it to memory.

[0057] In some optional steps, the entry into the kernel to perform the following customized operation (logging operation) mentioned in step 24 further includes: obtaining user space log information from memory; and generating logs based on the collected information includes: concatenating logs based on kernel space log information and user space log information.

[0058] In some optional steps, prior to step 25, the method further includes:

[0059] Step 23: Obtain the parameters of the reboot system call. Based on the correspondence of the events in the parameters, determine whether the reboot or shutdown operation was triggered by the user via the command line, or whether the reboot system call was executed by another process. If it is determined that the reboot or shutdown operation was triggered by the user via the command line, proceed to step 23. If it is determined that the reboot system call was executed by another process, proceed to step 24.

[0060] In some optional steps, after entering the kernel to perform the following logging operation in step 25, the method further includes: performing the shutdown and reboot operation indicated by the reboot system call after the log sending is completed.

[0061] In some optional steps, entering user space in step 24 to perform the following log writing operations further includes: after collecting user space log information and writing it to memory, performing operations to shut down the service and unmount the file system.

[0062] The technical effects achieved by the method in this application include, but are not limited to:

[0063] ① By performing customized operations in the kernel, log information in the kernel space can be obtained, including but not limited to information about the parent-child relationship tree of the shell process, thus obtaining more comprehensive log information.

[0064] ② By triggering the kernel module loading operation in user space, network parameters containing the IP address are passed to the kernel, enabling the kernel to send the collected logs to the recording device corresponding to the IP address over the network. The recording device is a general-purpose device, so no specific hardware support is required and it does not consume valuable pstore storage resources.

[0065] In summary, the method described in this application is simple to deploy and provides rich information feedback. It is particularly suitable for cluster environments with centralized batch management. It can be used in conjunction with open-source logging solutions such as Filebeat to quickly detect unreasonable power operation behaviors in large clusters and improve operational efficiency.

[0066] refer to Figure 3 , Figure 3 This is a block diagram illustrating the working principle of a Linux system shutdown and restart operation logging method according to an embodiment of this application. Combined with... Figure 3 As shown, the Linux system shutdown and restart logging method provided in this application may specifically include the following steps in its execution flow:

[0067] Step 1: When deploying this solution, an operation is pre-inserted into the user-space trigger module, that is, the operation of loading the pre-written kernel module - PowerActinPrint.ko module is triggered. At this time, the network parameters containing IP (Internet Protocol) address and NETMARK (subnet mask or network mask) can be passed to the kernel through the parameter passing function of the kernel module. The kernel will receive and store these two network parameters in a specific memory.

[0068] Here, the PowerActinPrint.ko module can be implemented using the general module writing methods of Linux systems. The module can utilize netlink (inter-process communication) technology; by using netlink in kernel space, data packets can be sent to a remote host. The implementation method for this part can refer to the mature module mechanisms of existing kernel modules. The key point of this application is to introduce this module, not how it is written and implemented.

[0069] Here, a logging device called a log service or log center can be set up in the cluster environment, specifically for recording logs. The two network parameters mentioned above can be the network parameters of this logging device; that is, the IP address and subnet mask are the IP address and subnet mask of the logging device, respectively. The existence of this device does not affect normal power-on operations such as shutdown and restart; it is only used for recording logs during power-on and shutdown operations.

[0070] Step two: A power operation is triggered, for example, if the user triggers a power operation (such as reboot, shutdown, poweroff, or any of the restart or shutdown operations) via a command line (a piece of code in systemd). The process will execute first. Figure 3 The user-space customized operation in the user space writes the obtained customized operation results (i.e., the collected user space log information) into a specific memory, and then performs operations such as shutting down the service and unloading the file system.

[0071] Here, we explain how to insert custom processes in user space. When a user directly calls a power operation (such as reboot, shutdown, or poweroff), this operation will first be recognized by the systemd program. These programs are themselves part of the systemd package's utility code. Therefore, by modifying the systemd code, the user-space customized operation code of this application can be executed before the power operation code such as shutdown or reboot is executed. This completes the user space log collection, and then the subsequent power operation code such as shutdown or reboot is executed.

[0072] Step 3, Entering Kernel Mode: The kernel executes the reboot system call. During this call, the kernel first performs a "kernel-mode customization operation." This operation collects log information from the kernel space, including the parent-child relationship tree of the user shell (the terminal executing system calls like reboot and poweroff). Logs are generated based on the collected information, and then sent to the recording device corresponding to the IP address obtained during module insertion, using the network parameters. The shell, commonly known as the "operating interface" (to distinguish it from the kernel), refers to the software that provides the user interface; the shell process can be expressed as the "shell process" in Chinese.

[0073] Here, we explain how to insert a custom flow into the reboot system call in the kernel. This can be achieved by utilizing the kernel's notification chain mechanism, such as... Figure 3 The diagram illustrates a customized kernel-mode operation flow. In the notification chain mechanism, when the state of a subsystem changes, a mechanism must be used to notify other subsystems using its services so that they can take appropriate action. To meet this requirement, the kernel implements an event notification chain mechanism. Regarding the reboot system call, the kernel provides the register_reboot_notifier system call to register the notification event. The functionality desired in this application can be implemented within the registered event handler function.

[0074] Step 4: After the kernel completes the data transmission, it continues with the remaining reboot steps, i.e., subsequent power operations such as shutdown and restart. The process ends upon successful completion. This concludes one complete execution cycle. The next time a power operation such as shutdown or restart occurs, the above process will continue.

[0075] It should be noted that, depending on the type of power operation, the above process can be executed in two different ways.

[0076] Method 1: Perform power operations such as shutdown and restart via command line.

[0077] If the user performs a shutdown or restart operation via command line, the system will first enter... Figure 3 The left half performs user-mode custom operations, and then enters... Figure 3 The right half of the process enters the kernel-mode customization operation. The results of the user-mode customization operation plus the results of the kernel-mode customization operation, that is, the log information in user space and the log information in kernel mode, together form the required log. Then, the network is started in kernel mode, and the generated log is delivered to a specific node (that is, the recording device indicated by the IP address passed through the kernel module, which is not local).

[0078] Method 2: Power operations such as shutdown and restart caused by other processes.

[0079] If the power-on operation, such as shutdown or restart, was not caused manually by the user, but rather by another process explicitly executing the reboot system call, this situation can be ignored. Figure 3 The left half of the code does not perform user-mode operations, but instead executes directly. Figure 3 The right half of the kernel-mode operation performs customized operations in the kernel, completes the collection of log information in the kernel space, and then starts the network to deliver the collected data as logs to the specific nodes mentioned above.

[0080] Please refer to Figure 4 The diagram shows the working principle block diagram corresponding to the second method described above. Figure 4 and Figure 3 The difference lies in the reduction of user-mode operation steps. For example... Figure 4 As shown, if the power-up operation, such as shutdown or reboot, is performed by another application directly calling the reboot system call provided by the kernel, instead of a user operation, then the following will not occur: Figure 3 The steps for collecting user-mode information are shown. That is, step two is optional and is skipped in method two.

[0081] In some alternative implementations, the parameters of the reboot system call can be obtained, and the power operation can be determined as either method one or method two based on the correspondence of the events in the parameters.

[0082] Specifically, before the reboot call in the kernel space during power operations such as shutdown and restart, the system can distinguish which power operation event (shutdown or restart) has occurred. This can be determined by the parameters of the reboot function, and the correspondence between the parameters and the events is as follows:

[0083] LINUX_REBOOT_CMD_CAD_OFF: A reboot caused by Ctrl-Alt-Del;

[0084] LINUX_REBOOT_CMD_RESTART: Reboot;

[0085] LINUX_REBOOT_CMD_POWER_OFF: Power off.

[0086] Based on the above correspondence, it can be determined that the current power operation event is either a restart or shutdown operation triggered by the user via command line, or a reboot system call executed by another process.

[0087] Whether Figure 3 Method 1 shown is still Figure 4 The shutdown process described in Method 2 will eventually enter the kernel's reboot system call process. Before entering the reboot call process, network parameter information needs to be prepared. This information will be used by the "kernel-mode customization operation". This information is passed to the kernel as a module parameter. It is passed to the kernel as a parameter when the module is loaded.

[0088] Here, after capturing a power operation event in the module code, the parent-child relationship tree of the current process (current->pid) can be captured simultaneously. Additionally, user-space log information and kernel-space stack log information are concatenated, network parameters are read from a specific memory space (this memory block is initialized via parameters during module initialization), the netlink network is initialized, and the concatenated log content is sent to the node (recording device) indicated by the aforementioned IP address.

[0089] Here, the organization of data structures in kernel space is explained as follows. The data to be sent after the kernel completes customized operations can include two parts: one part from user space (optional) and one part from kernel space. If the user performs power operations such as shutdown or reboot via command line, the data in user space exists; otherwise, the data in user space does not exist.

[0090] The above provides a detailed description of the technical solution for logging Linux system shutdown and restart operations provided in this application. This solution can be used to obtain logs of Linux system shutdown, restart, and other power operations, and can be customized to add shutdown and restart information, including but not limited to process parent-child relationship trees.

[0091] Specifically, the solution in this application can collect richer information during normal power-on operations such as shutdown and restart, including but not limited to the following:

[0092] ① Parent-child process relationships of processes that trigger power operations such as shutdown and restart;

[0093] ② Operation type (shutdown, restart), operation time (time the event occurred);

[0094] ③System load, the running queues of each core of the system;

[0095] The system now identifies which process triggered the shutdown or restart operation, and through what call relationships that process triggered the shutdown.

[0096] By acquiring information such as machine restarts and reboots, the maintainability and observability of the system can be improved.

[0097] ④ Optional user-mode modification (user-mode modification is not required).

[0098] The beneficial effects that can be achieved by adopting the above technical solution include, but are not limited to: simple deployment methods, rich information feedback, and are particularly suitable for centralized batch management cluster environments. When used in conjunction with open source logging solutions such as Filebeat, it can quickly detect unreasonable power operation behaviors in large clusters and improve operation and maintenance efficiency.

[0099] It is worth noting that in some other possible implementation schemes, such as Figure 3 The "kernel-mode customization operation" on the right side can also be found in, for example... Figure 3 The process is completed in the "User-mode Customized Operations" section on the left. Once completed, information can be delivered to the recording device via user-mode network operations or written directly to a file. However, this approach has the following problems: when shutdown fails (the process does not reach the kernel's reboot system call), this approach cannot recognize it, resulting in incorrect information recording; and it cannot recognize shutdowns or restarts not caused by command lines (i.e., power operations not manually caused by the user).

[0100] refer to Figure 5 , Figure 5This is a schematic diagram of a Linux system shutdown and restart operation logging device 500 according to an embodiment of this application. The Linux system shutdown and restart operation logging device 500 of this application can be applied to, for example... Figure 1 The system architecture shown is for server 102.

[0101] like Figure 5 As shown, the Linux system shutdown and restart operation logging device 500 of this application may include:

[0102] User-mode execution module 51 is configured to pass network parameters containing IP addresses to the kernel when a user-mode operation triggers the loading of a kernel module.

[0103] The kernel-mode execution module 52 is configured to enable the kernel to receive and store network parameters in memory; and, upon detecting a reboot system call, to enter the kernel and perform the following logging operations: collect log information in the kernel space, which includes information about the parent-child relationship tree of the shell processes in the current system; generate logs based on the collected information; read the IP address from the network parameters in memory, and send the logs over the network to the recording device corresponding to the IP address.

[0104] In some optional implementations, the user-mode execution module 51 is further configured to enter user mode and perform the following log writing operation before entering the kernel to perform the following logging operation: collect log information from user space and write it to memory.

[0105] In some optional implementations, the kernel-mode execution module 52 is further configured to obtain user-space log information from memory; and to generate logs based on the collected information, including: concatenating the kernel-space log information and the user-space log information to generate logs.

[0106] In some optional embodiments, the above apparatus further includes a kernel-mode judgment module; the kernel-mode judgment module is configured to obtain the parameters of the restart system call, and determine, based on the correspondence of the events in the parameters, whether the restart or shutdown operation is triggered by a user via command line, or whether the restart system call is executed by another process; if it is determined that the restart or shutdown operation is triggered by a user via command line, the user-mode execution module 51 is instructed to execute the step of entering user mode to perform the following log writing operation; if it is determined that the restart system call is executed by another process, the kernel-mode execution module 52 is instructed to execute the step of entering the kernel to perform the following log recording operation.

[0107] In some alternative implementations, the kernel-mode execution module 52 is further configured to perform the shutdown and restart operations indicated by the restart system call after the log is sent.

[0108] In some alternative implementations, the user-space execution module 51 is further configured to perform operations to shut down the service and unload the file system after collecting user-space log information and writing it into memory.

[0109] It should be noted that the implementation details and technical effects of each module in the device of this embodiment can be found in the descriptions of other embodiments in this application, and will not be repeated here. The implementation schemes of each module of this device are diverse, as long as the purpose of the module can be achieved, and the actual deployment is not limited to the specific implementation scheme.

[0110] refer to Figure 6 , Figure 6 This is a schematic diagram of the structure of a computer device for implementing a server according to an embodiment of this application. Figure 6 As shown, the computer device 600 of this application may include:

[0111] One or more processors 601;

[0112] Memory 602, on which one or more programs 603 are stored;

[0113] Components such as processor 601 and memory 602 can be coupled together via bus system 604; bus system 604 is used to realize the connection and communication between these components.

[0114] When one or more programs 603 are executed by one or more processors 601, the one or more processors 601 implement the logging method for Linux system shutdown and restart operations as disclosed in the above method embodiments.

[0115] The bus system 604 may include a data bus, a power bus, a control bus, and a status signal bus. The memory 602 may be volatile or non-volatile, or both. The processor 601 may be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0116] This application also provides a computer-readable storage medium storing a computer program thereon, which, when executed by one or more processors, implements a log recording method for Linux system shutdown and restart operations as disclosed in the above method embodiments.

[0117] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0118] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0119] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0120] It should be understood that the terms "system" and "network" are often used interchangeably in this application. The term "and / or" in this application is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Furthermore, the character " / " in this application generally indicates that the preceding and following related objects have an "or" relationship.

[0121] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application.

Claims

1. A method for logging a shutdown or reboot operation of a Linux system, characterized in that, include: When a user-space operation to load a kernel module is detected, network parameters containing the IP address are passed to the kernel. The kernel receives and stores the network parameters in memory; A reboot system call triggered by a normal shutdown or restart operation is detected. The reboot system call includes a reboot system call. The parameters of the reboot system call are obtained. Based on the correspondence of the events in the parameters, it is determined whether the restart or shutdown operation was triggered by the user via command line, or whether the reboot system call was executed by another process. If it is determined that the user triggered the restart or shutdown operation through the command line, then enter user mode to perform the following log writing operation: collect log information in user space and write it to memory, and then enter the kernel to perform log recording operation; If it is determined that the system restart call was executed by another process, then the kernel will be directly entered to perform the logging operation. The step of entering the kernel to perform logging operations is executed before the shutdown or restart operation indicated by the restart system call. The step of entering the kernel to perform logging operations includes: collecting log information in the kernel space, which includes information about the parent-child relationship tree of the shell processes in the current system; generating logs based on the collected information, wherein, when the log information in the user space exists in memory, logs are generated by concatenating the log information in the kernel space and the log information in the user space, otherwise logs are generated based on the log information in the kernel space; reading the IP address in the network parameters from memory, and sending the logs through the network to the recording device corresponding to the IP address, wherein the recording device does not include pstore storage.

2. The method of claim 1, wherein, After entering the kernel and performing the following logging operations, the method further includes: After the log is sent, the shutdown and restart operations indicated by the restart system call are executed.

3. The method of claim 1, wherein, The step of entering user space to perform the following log writing operations further includes: after collecting log information from user space and writing it into memory, performing operations to shut down the service and unload the file system.

4. A log recording apparatus for a linux system shutdown and restart operation, characterized by comprising: include: The user-mode execution module is configured to pass network parameters, including the IP address, to the kernel when the user-mode detects an operation that triggers the loading of a kernel module. The kernel-mode execution module is configured to enable the kernel to receive and store the network parameters in memory; and to detect a reboot system call triggered by a normal shutdown or restart operation, the reboot system call including the reboot system call, obtain the parameters of the reboot system call, and determine, based on the correspondence of the events of the parameters, whether the restart or shutdown operation was triggered by the user via the command line, or whether the reboot system call was executed by another process; If it is determined that the user triggered the restart or shutdown operation via command line, then the system enters user mode and performs the following log writing operation: collects log information from user space and writes it to memory, then enters the kernel to perform log recording operation; if it is determined that another process executed the restart system call, then the system directly enters the kernel to perform log recording operation; the step of entering the kernel to perform log recording operation is performed before executing the shutdown or restart operation indicated by the restart system call, and the step of entering the kernel to perform log recording operation includes: collecting log information from kernel space, which includes information on the parent-child relationship tree of the shell process in the current system; generating logs based on the collected information; reading the IP address from the network parameters from memory, and sending the logs over the network to the recording device corresponding to the IP address, wherein the recording device does not include pstore storage.

5. A computer device, comprising: include: One or more processors; Storage device, on which one or more programs are stored, When the one or more programs are executed by the one or more processors, the one or more processors cause the one or more processors to implement the method as described in any one of claims 1-3.

6. A computer readable storage medium characterized by, It stores a computer program that, when executed by one or more processors, implements the method as described in any one of claims 1-3.

Images