CN-121807612-B - Method and equipment for detecting and repairing glibc damage by Linux system

CN121807612BCN 121807612 BCN121807612 BCN 121807612BCN-121807612-B

Abstract

The invention discloses a method and equipment for detecting and repairing glibc damage of a Linux system, belonging to the technical field of computer data processing, wherein the method comprises the steps of identifying and mounting a damaged target operating system root file system after loading a designated INITRAMFS, establishing a condition of switching to a minimum chroot, scanning a designated glibc component of the target operating system, and constructing a dependency graph; executing a preset test and capturing error information for matching and identifying fault types, extracting a release version and a version identifier in a target operating system, determining a correct glibc version number and a file integrity check value, acquiring corresponding repair resources, replacing a damaged glibc file with the correct version by adopting atomic operation in a chroot environment, and finally verifying the execution condition of a core command and the loading condition of a library file. The invention can obviously improve the accuracy and efficiency of system library fault processing.

Inventors

CAO JINGBO
ZHANG JIANRONG
MO QINGLIANG

Assignees

联通数字科技有限公司

Dates

Publication Date: 20260505
Application Date: 20260312

Claims (8)

A method for detecting and repairing glibc damage in a linux system, comprising: after the assignment INITRAMFS is loaded, identifying and mounting a damaged target operating system root file system, establishing and switching to a minimized chroot environment, and simultaneously scanning executable files and glibc components depended on the executable files in the target operating system to construct a dependency graph; executing a preset test command, capturing generated runtime error information, and matching the error information with a predefined fault mode database to identify a fault type; Extracting release version and version identification in a target operating system, inquiring and determining correct glibc version number and file integrity check value from a preset source, selecting and acquiring corresponding repair resources from a preset software mirror image or a cache built in INITRAMFS according to the identified fault type; Replacing the glibc file of the damaged system with the correct version of the repair resource using atomic operations within the chroot environment; and running a health check script, and verifying the execution status of the core command and the loading status of the library file.
2. The method for detecting and repairing glibc damage in a Linux system of claim 1, wherein said assigning INITRAMFS an acquisition update procedure comprises: when the system is installed, a corresponding glibc library file in the execution process of the glibc damage diagnosis flow is obtained through dracut command, and a group of appointed initramfs files are constructed for loading hash values of the glibc library file; And comparing the version numbers of the glibc in the new version glibc installation process, if the new version glibc is updated in a cross-large version, not updating initramfs the file, and if the new version glibc is updated in a small version, updating initramfs the file.
3. The method for detecting and repairing glibc damage in Linux system according to claim 2, wherein said dependency graph is constructed by scanning system key services and binary files, based on dependency relationships of binary files and recursive dependencies of dependencies, and simplifying the dependency graph to obtain all relevant so files of final dependent glibc.
4. The method for detecting and repairing glibc damage in Linux system according to claim 1, wherein in said matching process of said failure mode database based on so file, the matching scene includes missing libc.so.6, version number mismatch, file authority error, wherein the failure mode database executes corresponding recovery operation according to the internally stored error information and corresponding processing method.
5. The method for detecting and repairing glibc damage in Linux system according to claim 4, wherein in the fault type identification process, correct glibc version number and hash value are determined according to system release information, the version number and hash value are glibc version when installing system, inquiry is performed through file record and result is compared, if result is the same, correction is successful, if not, correction is failed, and result is printed under root file system.
6. A device for automatically detecting and repairing a glibc damage by a Linux operating system, for executing a method for detecting and repairing a glibc damage by a Linux system according to any one of claims 1 to 5 in a initramfs environment, comprising: The starting and isolating module is used for identifying and mounting a damaged target operating system root file system after loading the appointed INITRAMFS, and finally establishing and switching to a minimized chroot environment; The intelligent diagnosis module is used for executing fault matching query operation of the glibc version number and the hash value based on chroot environments so as to confirm whether the glibc has faults or not; and the automatic recovery module is used for automatically executing the optimal repair strategy after the glibc confirms that the fault exists.
7. The device for automatically detecting glibc damage and automatically repairing a Linux operating system of claim 6, wherein said intelligent diagnostic module performs the following flow operations: The dependence graph analysis comprises the steps of mounting a real root file system, scanning glibc files of a target system and main dependence programs thereof, obtaining dependence of binary files, constructing a group of key dependence graphs after the dependence of the binary files is obtained, and simplifying the dependence graphs to obtain all sos files related to the glibc of the final dependence; performing error detection test, matching the test result with a predefined glibc fault mode database, and performing corresponding repair operation on an automatic recovery module after the fault detection test is matched with the corresponding fault report; And acquiring an expected state, namely automatically determining the correct glibc version number and hash value according to the system release version information, wherein the version number and the hash value at the moment are glibc versions when the system is installed, inquiring through file records, comparing the results, if the results are the same, correcting successfully, if the results are not the same, correcting failed, and finally outputting a correction judging result.
8. The apparatus for automatically detecting and automatically repairing a glibc damage of a Linux operating system according to claim 7, wherein the automatic recovery module performs a corresponding replacement correction operation, and runs a preset health check script after the replacement correction is completed, so as to verify whether the glibc has been repaired, and the replacement correction operation includes: if the versions are not matched, downloading the correct package from a preset mirror source or a cache built in initramfs; atomising replacement-within chroot environments, the damaged glibc file is replaced using atomic operations.

Description

Method and equipment for detecting and repairing glibc damage by Linux system Technical Field The invention relates to the technical field of computer data processing, in particular to a method and equipment for automatically detecting and repairing glibc damage by a Linux operating system. Background With the wide application of Linux operating systems in key fields such as servers, cloud computing, embedded equipment and the like, the stability of a system core shared library becomes an important foundation for guaranteeing service continuity. GNU C Library (glibc) is used as a core interface between the kernel and the application program of the operating system, and if the kernel is damaged or the version is not matched (for example, due to interruption or misoperation of the system upgrade), or the file authority is wrong, the system cannot load any user state program, so that the system is failed to start, and even in the boot stage, the kernel is crashed or continuously restarted. Currently, the mainstream repair method relies on external media such as emergency Mode (standby Mode) and Live CD/USB, and performs system mounting, environment switching, and library file diagnosis and replacement through manual operation. However, in the above method, since the repair process needs to manually execute complex commands and relies on deep understanding of the bottom layer of the system by operators, which results in low repair efficiency and high risk of errors, such as extremely high risk of manually replacing core library files (especially glibc), any intermediate operation errors may cause secondary damage, making the system completely unrecoverable, and the prior art also lacks a diagnostic system capable of automatically analyzing the dependency relationship of the damaged system, pattern matching failure types and automatically determining correct version information, so that the prior art has difficulty in meeting the requirement of high-availability production environment for rapid automatic recovery. Therefore, the application provides a method for detecting and repairing glibc damage by using a Linux system to solve the technical problems. Disclosure of Invention The invention mainly aims to provide a method for detecting and repairing glibc damage by a Linux system, which aims to solve the technical problems in the background technology. The invention adopts the following technical scheme to solve the technical problems: A method for detecting and repairing glibc damage by a Linux system, performed by a computer device, comprising the steps of: After the assignment INITRAMFS is loaded, automatically identifying and mounting a damaged target operating system root file system, establishing and switching to a minimized chroot environment, and simultaneously scanning key executable files and glibc components depended on the key executable files in the target operating system to construct a key dependency relationship graph so as to evaluate the influence range of faults; Automatically executing a predetermined test command (e.g., attempting to execute/rootmnt/bin/ls and capturing segment fault or link error), capturing generated runtime error information, matching the error information with a predefined failure mode database to accurately identify the failure type, including but not limited to library file missing, version mismatch, or file permission error; Extracting release version and version identification in a target operating system, automatically inquiring and determining correct glibc version number and file integrity check value from a preset source, and automatically selecting and acquiring corresponding repair resources from a preset software mirror image or a cache built in INITRAMFS according to the identified fault type as a repair reference; Replacing the glibc file of the damaged system with the correct version of the repair resource by adopting an atomic operation in chroot environment so as to ensure the atomicity and the safety of the replacement process; And automatically running a health check script, and verifying the execution status of the core command and the loading status of the library file to ensure that the glibc function is restored to be normal. Preferably, the acquiring update procedure of the specification INITRAMFS includes: when the system is installed, a corresponding glibc library file in the execution process of the glibc damage diagnosis flow is obtained through dracut command, and a group of appointed initramfs files are constructed for loading hash values of the glibc library file; And comparing the version numbers of the glibc in the new version glibc installation process, if the new version glibc is updated in a cross-large version, not updating initramfs the file, and if the new version glibc is updated in a small version, updating initramfs the file. Preferably, the dependency graph is constructed based on the dependency of the binary file and the recurs