Linux shared link library error solution example

Linux shared link library error solution: Linux Enterprise Application-Linux server application information. For details, refer to the following section. Author: Liu Ji-en, Chengdu Physical Education Institute, Sichuan Province
　　
Not long ago, a bank network administrator called the author and said that one of his Linux servers installed with databases could not be started. This Linux server stores very important bank data, help solve the problem. He told me that this Linux Server (installed with Red Hat 5.1 and kernel 2.0.34) has been running very well. Unfortunately, the UPS has encountered a problem and the power is down, and then the server is started. When it is started to init, the following error message is displayed:
INIT: 2.74 version booting
Can't find libc. so.6
　　
　　
Then the system cannot be started.
　　
　　 Q &
　　
In Linux, the shared link library is mainly placed in the/lib directory, with lib *. so. * as a typical file name. The shared link library in Linux is very important for Linux. Almost all programs need to call the shared link library, similar to the *. dll file in Windows.
　　
I first enter the single-user mode and enter Linux single at the "LILO:" prompt. The result also shows that the libc. so.6 file cannot be found! It seems that Linux calls the shared link library before reading the/etc/inittab file. Here, I will briefly introduce the Linux Startup Process: To start Linux, we must first boot the kernel, then perform device detection, and then call a process called init. The process follows certain rules, read the content of the/etc/inittab file and execute the relevant processes in the file to guide the system into a specific running rule process, that is, we all know the six modes: 0 is standby, 1 is single user, 2 is Multi-User Local Mode, 3 is multi-user network mode, 4 is reserved for the system, 5 is XWindows, 6 is restarted. The init process first calls the shared link library. Because an error occurs in the shared link library, the single-user mode cannot be entered now. It seems that you only need to use the boot disk and Repair Disk to enter the first-aid mode of Linux to try it. The repair program creates a boot disk and a Repair Disk. The author first uses the boot disk to boot the system and enters rescue at the "LILO:" prompt until the system prompts the author to insert the Repair Disk and enter the emergency mode. In emergency mode, many common commands are not available, and the root partition is not mounted because the kernel in the floppy disk is mapped to the memory, the/lib directory is on the Root partition. The author first hangs the root partition: mount-ext2/dev/hda1/mnt/hda1, enter the/lib directory, and run the ls command to view it, libc. so.6 exists, so I suspect that there is a problem with the super block or node, so I use the fsck command (in emergency mode, the general ext2 File System check Command e2fsck is not available ): fsck-B 8193/dev/hda1 and then exit and restart. As a result, the fault persists, and repeated fsck command checks cannot be solved.

　　
　　 Liu yinghuaming
　　
After a few times, I checked libc. so.6: ls-l libc. so.6 IN THE/lib directory and noticed that:
　　
Lrwxrwxrwx 1 root 13 Mar 10 0:32 libc. so.6-> libc-2 .?. 7. so
　　
The original libc. so.6 file is just libc-2 .?. 7. A link to the so file, which seems to have been omitted previously. There is a "?" , The problem may be here, init process to run the first to call the libc-2 .?. 7. so points to the link file libc. so.6, The init process really calls the libc-2 .?. 7. so, while libc-2 .?. 7. The so file certainly does not exist. so what should it be? Use ls to view, lib directory has a libc-2.0.7.so file, this file is really pointing to libc. so.6 file. The author executes "rm-f libc. so.6, ln-s libc-2.0.7.so libc. so.6", re-creates the correct link pointing to libc. so.6, and then exits and restarts, the failure still exists.
　　
　　 The water falls into stone
　　
But I always thought it was correct. I went to the lib directory and carefully read the libc. so.6 file: ls-l libc. so.6. The result is as follows:
　　
Lrwxrwxrwx 1 root 13 Mar 10 0:32 libc. so.6-> libc-2 .?. 7. so
　　
It seems that the operation I did was not written into the disk, So I performed the operation again. But this time I honestly "umount/dev/hda1", then quit and restarted, and the system restarted normally. Then I went to the lib directory and looked at libc. so.6: ls-l libc. so.6, the result is as follows:

Lrwxrwxrwx 1 root 13 Mar 10 libc. so.6-> libc-2.0.7.so
　　
This modification was written into the disk. It seems that the problem lies in the link of the libc. so.6 file. The problem is finally solved!
　　
　　 Postscript
　　
Why umount? In normal mode, umount is not performed, and operations can also be written into the disk. I checked the information to understand that Linux file system update is a complicated process. After the user program modifies the file system, for example, a write operation is performed, file data is modified in the kernel buffer. when the data is not written to the disk, the user process can still be executed. All data changes are reflected in the inode content. The disk data is actually updated asynchronously. It is very likely that the disk data will be updated after the write operation is completed for a long time. The sync Command forces all data cached on the disk to be written to the disk. if the system is terminated before the disk buffer information is written to the disk, the file system of the disk is in an unstable state. In normal mode, even if no umount operation is performed on the partition, the system will call the sync command to forcibly write all data cached on the disk to the disk before the restart, in the First Aid mode, you must perform the umount operation on the mounted partition before the system can call the sync command to forcibly write all the data buffered by the disk to the disk, please pay attention to this problem in emergency mode. In fact, the "reboot-n (Don't sync before reboot or halt)" command does not require the sync command to forcibly write all the data cached on the disk to the disk before restart, which can easily explain the problem.