CN106844177B

CN106844177B - LINUX log management method, device and system

Info

Publication number: CN106844177B
Application number: CN201710053351.2A
Authority: CN
Inventors: 幺爱利; 李波
Original assignee: Lenovo Beijing Ltd
Current assignee: Lenovo Beijing Ltd
Priority date: 2017-01-23
Filing date: 2017-01-23
Publication date: 2020-08-25
Anticipated expiration: 2037-01-23
Also published as: CN106844177A

Abstract

The disclosure provides a LINUX log management method, a LINUX log management device and a LINUX log management system. The method comprises the following steps: when the LINUX system is started, registering a kernel console of the NVDIMM storage equipment; when generating a system log, writing the system log into the NVDIMM storage device through a kernel console of the NVDIMM storage device. The technical scheme of the system and the method can enable the LINUX system log to be timely output, completely stored and conveniently read even if the system is abnormal, and provide great convenience for solving the running condition of the system.

Description

LINUX log management method, device and system

Technical Field

The present disclosure generally relates to the field of computer technologies, and in particular, to a LINUX log management method, apparatus, and system.

Background

The LINUX system log is very important for knowing the running condition of the LINUX system, and can help to locate system problems particularly when the system is abnormal. For example, the system log may be dispatched to the messages file by a user-mode task for viewing when needed. However, when the LINUX system is abnormal, user-mode tasks or system scheduling is often blocked, and the system logs cannot be synchronized into the messages file, so that the system logs are lost.

Disclosure of Invention

One aspect of the present disclosure provides a LINUX log management method, including: when the LINUX system is started, registering a kernel console of the NVDIMM storage equipment; when generating a system log, writing the system log into the NVDIMM storage device through a kernel console of the NVDIMM storage device.

Optionally, before registering the core console of the NVDIMM memory device, the method further includes: determining whether there is a physical NVDIMM storage device in the system; upon determining that a physical NVDIMM storage device is not present in the system, a block of memory is designated from the memory as a virtual NVDIMM storage device.

Optionally, the LINUX log management method further includes: and when the system is restarted and recovered, reading a system log from the NVDIMM storage device through a kernel console of the NVDIMM storage device.

A second aspect of the present disclosure provides a LINUX log management apparatus, comprising: the registration module is configured to register a kernel console of the NVDIMM storage device when the LINUX system is started; a log output module configured to write, by a kernel console of the NVDIMM storage device, the system log into the NVDIMM storage device when the system log is generated.

Optionally, the LINUX log management apparatus further includes: an identification module configured to determine whether there are physical NVDIMM storage devices in the system; a virtual module configured to designate a block of memory from the memory as a virtual NVDIMM storage device upon determining that a physical NVDIMM storage device is not present in the system.

Optionally, the LINUX log management apparatus further includes: the log reading module is configured to read a system log from the NVDIMM storage device through a kernel console of the NVDIMM storage device when a reboot recovery of the system occurs.

A third aspect of the present disclosure provides a LINUX log management system, comprising: an NVDIMM storage device; and at least one processor, which executes the executable instructions to implement the LINUX log management method provided by the first aspect of the present disclosure.

Drawings

For a more complete understanding of the present disclosure and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

FIG. 1 schematically illustrates a flow chart of a LINUX log management method according to an embodiment of the disclosure;

fig. 2 schematically illustrates a flow chart of a method of a virtual NVDIMM storage device of an embodiment of the present disclosure;

FIG. 3 schematically illustrates a flow chart of a LINUX log management method according to another embodiment of the disclosure;

fig. 4 schematically shows a block diagram of a LINUX log management apparatus according to an embodiment of the present disclosure; and

fig. 5 schematically illustrates a block diagram of a LINUX log management system according to an embodiment of the present disclosure.

Detailed Description

Other aspects, advantages, and salient features of the disclosure will become apparent to those skilled in the art from the following detailed description, which, taken in conjunction with the annexed drawings, discloses exemplary embodiments of the disclosure.

In the present disclosure, the terms "include" and "comprise," as well as derivatives thereof, mean inclusion without limitation; the term "or" is inclusive, meaning and/or.

In this specification, the various embodiments described below which are used to describe the principles of the present disclosure are by way of illustration only and should not be construed in any way to limit the scope of the invention. The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of exemplary embodiments of the present disclosure as defined by the claims and their equivalents. The following description includes various specific details to aid understanding, but such details are to be regarded as illustrative only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Moreover, descriptions of well-known functions and constructions are omitted for clarity and conciseness. Moreover, throughout the drawings, the same reference numerals are used for similar functions and operations.

Some block diagrams and/or flow diagrams are shown in the figures. It will be understood that some blocks of the block diagrams and/or flowchart illustrations, or combinations thereof, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus, such that the instructions, which execute via the processor, create means for implementing the functions/acts specified in the block diagrams and/or flowchart block or blocks.

The LINUX system log can be written into the equipment corresponding to the kernel console through the kernel console, and is not influenced by user mode tasks or system scheduling. For example, a serial device may be externally connected to an electronic device running the LINUX system, and a kernel console corresponding to the serial device may be loaded in the LINUX system, so as to write a system log into the serial device. However, this requires, on the one hand, the provision of an interface for the electronic device to connect to a serial device and, on the other hand, the assurance that the serial device is connected to the electronic device and recognized by the LINUX system in the event of an abnormality in the LINUX system. If the serial device is not connected to the electronic device when the LINUX system is abnormal or the LINUX system does not recognize the serial device, the corresponding system log may be lost.

According to various embodiments of the disclosure, a LINUX log management method is provided. The method includes the steps that a kernel console of NVDIMM storage equipment is registered when a LINUX system is started; and when the system log is generated, writing the system log into the NVDIMM storage device through a kernel console of the NVDIMM storage device.

According to various embodiments of the present disclosure, an NVDIMM memory device integrates DRAM and non-volatile memory chips, capable of completely saving data when completely powered off. Therefore, the kernel console of the NVDIMM storage device is registered when the LINUX system is started, the system log is written into the NVDIMM storage device in real time, and the condition that the system log cannot be recovered can be avoided when the system is abnormal such as power failure. Therefore, when the LINUX system is abnormal, the kernel console of the NVDIMM storage device can still write the system log into the NVDIMM storage device through the output function (printk function) of the system log without being affected.

In addition, the NVDIMM storage device is in a memory bank specification integrating a DRAM and a nonvolatile memory chip, and can still completely store data stored in the LINUX system when the LINUX system is restarted and restored. When the NVDIMM storage equipment is abnormally powered off, the super capacitor can supply power to store data in the DRAM to the NAND flash memory; when the power is restored, data is read from the NAND flash memory, and the DRAM is restored to the power-off state. By the mode, the system log generated when the LINUX system is abnormal can be completely stored in the NVDIMM storage device, and can be conveniently checked after the LINUX system is restarted, so that great convenience is provided for positioning system problems and eliminating system faults.

According to embodiments of the present disclosure, registering NVDIMM memory devices may be preceded by determining whether there are physical NVDIMM memory devices in the LINUX system. When an entity NVDIMM storage device exists in the LINUX system, a core console corresponding to the entity NVDIMM storage device can be registered. In this case, data written to the physical NVDIMM memory device via the NVDIMM kernel console will not be lost and changed when the LINUX system is reset either from power down or not. When no physical NVDIMM storage device exists in the LINUX system, a block of memory may also be specified from the memory as a virtual NVDIMM storage device, and then a kernel console corresponding to the virtual NVDIMM storage device is registered. For a virtual NVDIMM storage device, when the LINUX system is abnormal, the system log can be acquired from the virtual NVDIMM storage device in a corresponding mode under the condition that the power is not cut off and reset.

Fig. 1 schematically shows a flowchart of a LINUX log management method according to an embodiment of the present disclosure. As shown in fig. 1, a LINUX log management method of an embodiment includes the following steps:

step 110: and registering a kernel console of the NVDIMM storage device when the LINUX system is started.

The log output function of the LINUX system is a printk function, and in the embodiment, the printk function is called by registering a kernel console of the NVDIMM storage device, so that the system log is output to the NVDIMM storage device. The NVDIMM memory device of this embodiment may be a physical NVDIMM memory device or a virtual NVDIMM memory device. For a physical NVDIMM memory device, for example, the physical NVDIMM memory device may be directly mounted on an electronic device running the LINUX system. For electronic devices without a physical NVDIMM storage device, a block of memory may be designated as a virtual NVDIMM storage device from memory at the time of kernel compilation using virtual NVDIMM technology.

Step 120: when the system log is generated, the system log is written into the NVDIMM memory device through a kernel console of the NVDIMM memory device.

The system log is continuously generated during the operation of the LINUX system. The kernel console of the NVDIMM storage device monitors whether the printk function outputs system logs in real time, and when the printk function outputs the system logs, the kernel console of the NVDIMM storage device outputs the system logs acquired from the printk function to the corresponding NVDIMM storage device. The printk function is embedded with the kernel code execution path and is not influenced by system task scheduling. Therefore, even if a system exception occurs, for example, the system has pancic, or a system scheduling problem occurs, the system log can be written into the NVDIMM storage device without being affected.

According to an embodiment of the present disclosure, as shown in fig. 2, before the step 110, the following steps are further included:

at step 210, it is determined whether there are physical NVDIMM storage devices in the system.

In this embodiment, when the LINUX system is started and before the kernel console of the NVDIMM memory device is registered, it is determined whether the electronic device running the LINUX system is provided with the physical NVDIMM memory device. For example, after the LINUX system is started, the NVDIMM driver is loaded, and whether the electronic device running the LINUX system is provided with the physical NVDIMM storage device is scanned.

In step 220, upon determining that there is no physical NVDIMM storage device in the system, a block of memory is designated from the memory as a virtual NVDIMM storage device.

For example, at the time of kernel compilation, the following options are enabled:

when the LINUX system is started, the related name (persistent memory) parameter is transmitted, a piece of memory is appointed in the memory to be used as a virtual NVDIMM storage area, and the virtual NVDIMM storage area cannot be used for other non-appointed purposes except for the NVDIMM kernel console. Moreover, the position and the content of the data stored in the virtual NVDIMM storage area can not be changed under the condition that the LINUX system is not powered off and reset and the BIOS is not emptied of the memory.

The embodiment is applied to the condition that no entity NVDIMM storage device exists in the LINUX system, and provides an effective optional mode for the system log management method of the electronic device without the entity NVDIMM storage device.

Certainly, in other embodiments, if the electronic device is provided with the entity NVDIMM storage device, the core console corresponding to the entity NVDIMM storage device may be directly registered in the LINUX system, so as to read and write data from and to the NVDIMM storage device.

Fig. 3 schematically shows a flow chart of a LINUX log management method according to another embodiment of the present disclosure. As shown in fig. 3, a LINUX log management method of another embodiment includes:

at step 310, when the LINUX system is started, a kernel console of the NVDIMM memory device is registered.

The NVDIMM memory device of this embodiment may be a physical NVDIMM device or a virtual NVDIMM memory device. For the physical NVDIMM memory device, for example, it may be an NVDIMM memory device installed in an electronic device running the LINUX system. For devices without physical NVDIMM storage, a block of memory may be designated from memory as a virtual NVDIMM storage device at kernel compile time using virtual NVDIMM technology.

In step 320, when the system log is generated, the system log is written into the NVDIMM memory device through the kernel console of the NVDIMM memory device.

The log output function of the LINUX system is a printk function. In this embodiment, a kernel console of the NVDIMM memory device monitors whether the printk function has system log output in real time. When the printk function is monitored to output the system log, the kernel console of the NVDIMM storage device outputs the system log acquired from the printk function to the corresponding NVDIMM storage device. The printk function is embedded with the kernel code execution path and is not influenced by system task scheduling. Thus, even when a system anomaly occurs, such as a system pancic, or a system scheduling problem occurs, the system log can be written to the NVDIMM storage device unaffected.

In step 330, when the system is restarted and recovered, the system log is read from the NVIDIMM storage device through the kernel console of the NVIDIMM storage device.

In the log management method of this embodiment, when the LINUX system is restarted and recovered, especially, for example, when the LINUX system is caused by a system abnormal condition during the restart and recovery, the system log of the abnormal condition may be read from the NVIDIMM storage device through the kernel console of the NVIDIMM storage device, so as to help locate a system problem and provide great convenience for removing a system fault.

Fig. 4 schematically shows a block diagram of a LINUX log management apparatus according to an embodiment of the present disclosure. As shown in fig. 4, the LINUX log management apparatus 400 of an embodiment includes a registration module 410 and a log output module 420. Wherein the registration module 410 is configured to register a kernel console of the NVDIMM memory device upon LINUX system boot; the journal output module 420 is configured to write the system journal into the NVDIMM storage device through a kernel console of the NVDIMM storage device when generating the system journal.

In this embodiment, the registration module 410 registers a kernel console of the NVDIMM memory device in the LINUX system, and is used for reading and writing data of the NVDIMM memory device. The registered NVDIMM kernel console can read, display, etc. data on the NVDIMM storage devices. The NVDIMM memory devices may be physical NVDIMM devices or virtual NVDIMM memory devices. For example, the physical NVDIMM memory device may be directly mounted on an electronic device running the LINUX operating system. For electronic devices without a physical NVDIMM storage device, a block of memory may be designated as a virtual NVDIMM storage device from memory at the time of kernel compilation using virtual NVDIMM technology.

In this embodiment, when the LINUX system generates the system log, the log output module 420 outputs the system log to the NVDIMM storage device through the kernel console of the NVDIMM storage device. The journal output function (printk function) used by the journal output module 420 may be called by the kernel console of the NVDIMM memory device registered by the registration module. In this way, the log output module 420 may output the generated system log to the NVDIMM memory device through a kernel console of the NVDIMM memory device. The log output function used by the log output module 420, namely the printk function, is embedded with a kernel code execution path and is not influenced by system task scheduling. Therefore, even if a system abnormality occurs, for example, when the system has pancic or a system scheduling problem occurs, the log output module 420 can write the generated system log into the NVDIMM storage device without being affected.

In the apparatus of this embodiment, whenever the LINUX system generates a system log, the log output module 420 may write the system log into the NVDIMM storage device in real time through the NVDIMM kernel console registered by the registration module 410. In addition, the NVDIMM storage device is in a memory bank specification integrating a DRAM and a nonvolatile memory chip, and can still completely store data stored in the LINUX system when the LINUX system is restarted and restored. In this way, the apparatus of the present embodiment can achieve efficient output and perfect preservation of the system log.

The LINUX log management apparatus 400 of an embodiment further includes an identification module 430. The identification module 430 is configured to determine if there is an entity NVIDIMM storage device in the system.

The identification module 430 may, for example, load an NVDIMM driver into the system after the LINUX system is started, and scan whether a physical NVDIMM memory device is disposed in the electronic device running the LINUX system. In one case, the recognition module 430 recognizes that an entity's NVDIMM memory device exists in the system, and the registration module 410 can directly register the kernel console of the entity's NVDIMM memory device in the LINUX system. Alternatively, the identification module 430 may not identify the physical NVDIMM memory device, i.e., indicating that there is no physical NVDIMM memory device in the LINUX system. In this case, the NVDIMM storage device may be virtualized through virtual technology.

The LINUX log management apparatus 400 of an embodiment further includes a virtual module 440. The virtual module 440 is configured to designate a block of memory from memory as a virtual NVIDIMM storage device upon determining that a physical NVIDIMM storage device is not present in the system.

When the virtual module 440 virtualizes the NVIDIMM storage device from memory, the following options may be enabled, for example, at kernel compilation time:

the virtual module 440 passes the relevant name memory parameter at LINUX system boot, designating a block of memory as a virtual NVDIMM memory region in memory that will not be used for other non-designated purposes than NVDIMM kernel console. Moreover, the position and the content of the data stored in the virtual NVDIMM storage area can not be changed under the condition that the LINUX system is not powered off and reset and the BIOS is not emptied of the memory.

In this embodiment, the virtual module 440 is configured to expand the application range of the LINUX log management apparatus 400, so that the apparatus 400 of this embodiment may also be applied to an electronic device without an actual NVDIMM memory device.

The LINUX log management apparatus 400 of an embodiment further includes a log reading module 450. The log reading module 450 is configured to read the system log from the NVIDIMM storage device through a kernel console of the NVDIMM storage device when a reboot recovery of the system occurs.

When the LINUX system restarts and recovers, particularly, for example, when such restarting and recovering is caused by a system abnormal condition, the log reading module 450 may read the system log of the abnormal condition from the NVIDIMM storage device through the kernel console of the NVIDIMM storage device.

The LINUX log management apparatus 400 of this embodiment can write the system log generated by the LINUX system into the NVDIMM storage device, and read the system log from the NVDIMM storage device when the LINUX system is restarted and restored, thereby ensuring timely output, complete storage, and convenient reading of the system log. The device of the embodiment provides great convenience for positioning system problems and eliminating system faults particularly when the LINUX system is abnormal.

Fig. 5 schematically illustrates a block diagram of a LINUX log management system according to an embodiment of the present disclosure. As shown in fig. 5, LINUX log management system 500 includes a processor 510 and NVDIMM storage 520. Processor 510 may be, for example, a general purpose microprocessor, an instruction set processor and/or associated chipset, and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), among others. The processor 510 may also include on-board memory for caching purposes. NVDIMM storage 520 includes physical NVDIMM storage 521 and virtual NVDIMM storage 522. In general, virtual NVDIMM storage 522 is a method for designating a block of memory from memory as a virtual NVDIMM storage by, for example, the virtual NVDIMM storage described in fig. 2 when it is determined that no physical NVDIMM storage exists in the LINUX system. Processor 510 may be a single processing unit or a plurality of processing units for performing the different actions of the method flows according to the various embodiments of the present disclosure described with reference to any of fig. 1-3.

The LINUX log management system 500 of an embodiment may further include an input unit 530 for receiving signals from other entities and/or modules, and an output unit 540 for providing signals to other entities and/or modules. The input unit 530 and the output unit 540 may be arranged as a single entity or as separate entities. The input unit 530 and the output unit 540 may be under the control of the processor 510 for interaction of the LINUX log management system 500 with other parts of the LINUX system.

The above methods, apparatuses, units and/or modules according to embodiments of the present disclosure may be implemented by an electronic device with computing capabilities executing software containing computer instructions. The system may include storage devices to implement the various storage described above. The computing-capable electronic device may include, but is not limited to, a general-purpose processor, a digital signal processor, a special-purpose processor, a reconfigurable processor, and the like capable of executing computer instructions. Execution of such instructions causes the electronic device to be configured to perform the operations described above in accordance with the present disclosure. The above devices and/or modules may be implemented in one electronic device, or may be implemented in different electronic devices. Such software may be stored in a computer readable storage medium. The computer readable storage medium stores one or more programs (software modules) comprising instructions which, when executed by one or more processors in an electronic device, cause the electronic device to perform the methods of the present disclosure.

Such software may be stored in the form of volatile memory or non-volatile storage (such as storage devices like ROM), whether erasable or rewritable, or in the form of memory (e.g. RAM, memory chips, devices or integrated circuits), or on optically or magnetically readable media (such as CD, DVD, magnetic disks or tapes, etc.). It should be appreciated that the storage devices and storage media are embodiments of machine-readable storage suitable for storing one or more programs that include instructions, which when executed, implement embodiments of the present disclosure. Embodiments provide a program and a machine-readable storage device storing such a program, the program comprising code for implementing the apparatus or method of any one of the claims of the present disclosure. Further, these programs may be delivered electronically via any medium (e.g., communication signals carried via a wired connection or a wireless connection), and embodiments suitably include these programs.

Methods, apparatus, units and/or modules according to embodiments of the present disclosure may also be implemented using hardware or firmware, or in any suitable combination of software, hardware and firmware implementations, for example, Field Programmable Gate Arrays (FPGAs), Programmable Logic Arrays (PLAs), system on a chip, system on a substrate, system on a package, Application Specific Integrated Circuits (ASICs), or in any other reasonable manner for integrating or packaging circuits. The system may include a storage device to implement the storage described above. When implemented in these manners, the software, hardware, and/or firmware used is programmed or designed to perform the corresponding above-described methods, steps, and/or functions according to the present disclosure. One skilled in the art can implement one or more of these systems and modules, or one or more portions thereof, using different implementations as appropriate to the actual needs. Such implementations are within the scope of the present disclosure.

While the disclosure has been shown and described with reference to certain exemplary embodiments thereof, it will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims and their equivalents. Accordingly, the scope of the present disclosure should not be limited to the above-described embodiments, but should be defined not only by the appended claims, but also by equivalents thereof.

Claims

1. A LINUX log management method comprises the following steps:

when the LINUX system is started, registering a kernel console of the NVDIMM storage equipment;

monitoring whether a log output function of the LINUX system has system log output or not in real time through a kernel console of the NVDIMM storage device; and

when monitoring that the system log is output by the log output function of the LINUX system, writing the system log into the NVDIMM storage device through the kernel console of the NVDIMM storage device.

2. The method of claim 1, wherein prior to registering the core console of the NVDIMM storage device, further comprising:

determining whether there is a physical NVDIMM storage device in the system;

upon determining that a physical NVDIMM storage device is not present in the system, a block of memory is designated from the memory as a virtual NVDIMM storage device.

3. The method of claim 1, further comprising:

and when the system is restarted and recovered, reading a system log from the NVDIMM storage device through a kernel console of the NVDIMM storage device.

4. A LINUX log management apparatus, comprising:

the registration module is configured to register a kernel console of the NVDIMM storage device when the LINUX system is started;

the log output module is configured to monitor whether a log output function of the LINUX system has system log output or not in real time through a kernel console of the NVDIMM storage device, and when the log output function of the LINUX system is monitored to output a system log, the system log is written into the NVDIMM storage device through the kernel console of the NVDIMM storage device.

5. The apparatus of claim 4, further comprising:

an identification module configured to determine whether there are physical NVDIMM storage devices in the system;

a virtual module configured to designate a block of memory from the memory as a virtual NVDIMM storage device upon determining that a physical NVDIMM storage device is not present in the system.

6. The apparatus of claim 4, further comprising:

the log reading module is configured to read a system log from the NVDIMM storage device through a kernel console of the NVDIMM storage device when a reboot recovery of the system occurs.

7. A LINUX log management system, comprising:

an NVDIMM storage device;

at least one processor implementing the method of any one of claims 1-3 by executing executable instructions.