Package class fault scheduling in Linux

Package class failures are more common in Linux systems, such as: when you need to compile the source package program, the system does not have the GCC compilation tool installed, the installation of the RPM software package has unresolved dependencies, the library file or header file installation path is incorrect, and so on, the package class failure causes a lot of Usually only need to be based on the appropriate error message to confirm the installation of the compilation environment, find the required dependency software package, correct the library file or the corresponding header file path.

The following is a major introduction to the failure of the RPM database and the ". So" file.

1, the RPM database damage

The failure of the RPM database is rare, the reason for this failure is usually due to forced shutdown, mistakenly delete the running files, forced to replace some of the RPM package files. When you use the RPM tool to query or install software, the RPM database will not function correctly when it is damaged.

Eg: simulate the RPM database corruption failure and verify the error message.

As a software package management mechanism in Linux, RPM maintains a separate file database for the installation of RPM package information in the system. When the data file is corrupted, the rpm command or Yum command is not available to query, install, upgrade, and delete the RPM package. To resolve this failure, you typically only need to perform the "RPM--REBUILDDB" command to rebuild the database.

Ps: This system httpd package has been installed!

Eg: clears the corrupted RPM data file and rebuilds the database information.

Look at the picture hints can be it!

2, Missing *.so class files

When the software package is installed through the source code, the executable file, function library and configuration file of the program will normally be installed to the corresponding location under the/usr/local directory (if your program is installed under "/usr/local", for example:/usr/local/mysql/ Bin,/usr/local/mysql/lib, etc.) to differentiate it from the related directory of the System program.

The *.so file is a library file, just like a. dll file in a Windows system. The normal installation and operation of a program requires support for specific library files. Because directories similar to "/usr/local/mysql/lib" are not included in the default library file path for Linux systems, if you need to use the dynamic link library files in these directories when installing additional packages, you will not be able to find them, resulting in an error message with the ". So" file missing.

This column more highlights: http://www.bianceng.cn/OS/Linux/

In the RHEL5 system, the configuration file "/etc/ld.so.conf" records the default search path for the dynamic-link library. When you need to add a new library file search path, you must modify the file appropriately, and then execute the "ldconfig" command to re-read the new configuration information.

Eg: Add the "/usr/local/mysql/lib/mysql" directory to the system's library file search path.
vi/etc/ld.so.conf                //Add a row of records to the end of the file
/usr/local/mysql/lib/mysql
ldconfig

When you install a new application, if you are prompted for a missing ". So" file, you should first use the Find command to look for the corresponding file in the system, and if it does not exist, the dependent software that provides the link library is not installed, you need to get the appropriate package and install it first. If the corresponding ". So" file already exists in the system, you can resolve the problem of the library file search by modifying the ld.so.conf file.

3. Repair File System

Linux hosts often cause file system damage due to abnormal shutdown, sudden power outages, and device data read and write exceptions. More common is the Super Block (Super-block) damage, the Super block is the core file system "file", it records the file system type, size, free disk blocks and other information. When the file system's Super block data is corrupted, Linux will not be able to recognize the filesystem and will not be able to mount the use.

When there is an error in the file system that is automatically loaded through the "/etc/fstab" profile, the Linux system automatically detects when it is turned on and prompts the user to fix the file system, such as when the "/DEV/SDB1" Partition's Super block has an error, the system prompts " Give root password for maintenance "

At this point, you only need to enter the root password, you can enter a temporary shell environment, where the user can be the error of the file system repair. Fix general file system errors you can use the fsck command to specify the file system type with the "-t" option, combining "-Y" to choose to automatically answer "yes" to the problem you are discovering. It is important to note that if the file system is compromised seriously, some data may still be lost after the repair is complete, so be careful to decide whether to fix it.

Eg: Use the fsck command to repair the Ext3 file system located in the "/DEV/SDB1" partition.

Fsck-yt ext3/dev/sdb1
Exit                    //Exit temporary shell environment will automatically restart.