在處理Linux系統出現的各種故障時，故障的癥狀是最先發現的，而導致這以故障的原因才是最終排除故障的關鍵。熟悉Linux系統的日誌管理，了解常見故障的分析與解決辦法，將有助於管理員快速定位故障點。“對癥下藥”及時解決各種系統問題。

日誌分析及管理

日誌文件是用於記錄Linux系統中各種運行消息的文件，相當於Linux主機的“日記”。不同的日誌文件記載了不同類型的信息，如：Linux內核消息，用戶登錄記錄，程序錯誤等。日誌文件對於診斷和解決系統中的問題很有幫助，因為在Linux系統中運行的程序通常會把系統消息和錯誤消息寫入相應的日誌文件，這樣系統一旦出現問題就會“有據可查”。此外，當主機遭受攻擊時，日誌文件還可以幫助尋找攻擊者留下的痕跡。下面我來對Linux系統中的主要日誌及分析管理方法進行介紹。

1、主要日誌文件包括以下三種類型：

>內核及系統日誌：這種日誌數據由系統服務syslog統一管理，根據其主配置文件"/etc/syslog.conf"中的設置決定將內核消息及各種系統程序消息記錄到什麽位置。系統中有相當一部分程序會把自己的日誌文件交由syslog管理，因而這些程序使用的日誌記錄也具有相似的格式。

>用戶日誌：這種日誌數據用於記錄Linux系統用戶登錄及退出系統的相關信息，包括用戶名、登錄的終端、登錄時間、來源主機、正在使用的進程操作等。

>程序日誌：有些應用程序運會選擇自己來獨立管理一份日誌文件（而不是交給syslog服務管理），用於記錄本程序運行過程中的各種事件信息。由於這些程序只負責管理自己的日誌文件，因此不同的程序所使用的日誌記錄格式可能會存在極大差異。

Linux系統本身和大部分服務器程序的日誌文件默認情況下都放置在目錄“/var/log”中。一部分程序共用一個日誌文件，一部分程序使用單個日誌文件，而有些大型服務器程序由於日誌文件不至一個，所以會在“/var/log/”目錄中建立相應的子目錄來存放日誌文件，這樣既保證了日誌文件目錄的結構清晰，又可以快速地定位日誌文件。有相當一部分日誌文件只有root用戶才有權限讀取，這保證了相關日誌信息的安全性。

>>>>>>>>：列表查看"/var/log"目錄中的各種日誌文件及子目錄。

對於Linux系統中的一些常見日誌文件，有必要熟悉其相應的用途，這樣才能在需要的時候更快地找到問題所在，及時解決各種故障。如：

1. >/var/log/messages：記錄Linux內核消息及各種應用程序的公共日誌信息，包括啟動、IO錯誤、網絡錯誤、程序故障等。對於未使用獨立日誌文件的應用程序或服務，一般都可以從該文件獲得相關的事件記錄信息。
2. >/var/log/cron：記錄crond計劃任務產生的事件消息。
3. >/varlog/dmesg：記錄Linux系統在引導過程中的各種事件信息。
4. >/var/log/maillog：記錄進入或發出系統的電子郵件活動。
5. >/var/log/lastlog：最近幾次成功登錄事件和最後一次不成功登錄事件。
6. >/var/log/rpmpkgs：記錄系統中安裝各rpm包列表信息。
7. >/var/log/secure：記錄用戶登錄認證過程中的事件信息。
8. >/var/log/wtmp：記錄每個用戶登錄、註銷及系統啟動和停機事件。
9. >/var/log/utmp：記錄當前登錄的每個用戶的詳細信息

2、日誌文件分析

熟悉了系統中的主要日誌，我們就針對日誌文件的分析方法做了解。分析日誌文件的目地在於通過瀏覽日誌查找關鍵信息，對系統服務進行調試，判斷發生故障的原因等。這裏主要說三類日誌文件的基本格式和分析方法。

對於大多數文本格式的日誌格式（如內核及系統日誌、大多數的程序日誌），只要使用tail、more、less、cat等文本處理工具就可以查看日誌內容。而對於一些二進制格式的日誌文件（eg：用戶日誌），則需要使用相應的查詢命令。

>內核及系統日誌：

內核及系統日誌功能主要由默認安裝的syslogd-1.4.1-39.2軟件包提供，該軟件包安裝了klogd、syslogd兩個程序，並通過syslog服務進行控制，分別用於記錄系統內核的消息和各種應用程序的消息。syslog服務所使用的配置文件為"/etc/syslog.conf"。

通常情況下，內核及大多數系統消息都被記錄到公共日誌文件"/var/log/messages"中，而其他一些程序消息被記錄到不同的文件中，日誌消息還能夠記錄到特定的存儲設備中，或者直接向用戶發送。

>>>>>查看日誌配置文件"/etc/syslog.conf‘中的內容

從配置文件"/etc/syslog.conf“中可以看到，受syslogd服務管理的日誌文件都是Linux系統中最主要的日誌文件，他們記錄了Linux系統中內核、用戶認證、郵件、計劃任務等最基本的系統消息。在Linux內核中，根據日誌消息的重要程度不同，將其分為不同的優先級別（數字等級越小，優先級越高，消息越重要）。

1. >0 EMERG(緊急)：會導致主機系統不可用的情況。
2. >1 ALERT(警告)：必須馬上采取措施解決的問題。
3. >2 CRIT（嚴重）：比較嚴重的情況。
4. >3 ERR（錯誤）：運行出現錯誤。
5. >4 WARNING(提醒)：可能影響系統功能，需要提醒用戶的重要事件。
6. >5 NOTICE(註意)：不會影響正常功能，但是需要註意的事件。
7. >6 INFO (信息)：一般信息。
8. >7 BEBUG(調試)：程序或系統調試信息等。

對於syslog服務統一管理的大部分日誌文件，使用的日誌記錄格式基本上都是相同的，下面以公共日誌文件"/var/log/messages"為例來說明內核及系統日誌記錄的基本格式。

eg：查看公共日誌文件"/var/log/messages"的最後兩行記錄。

日誌文件中的每一行表示一條消息，每個消息均由四個字段的固定格式組成。

1. >：時間標簽：消息發出的日期和時間。
2. >：主機名：生成消息的計算機的名稱。
3. >：子系統名稱：發出消息的應用程序的名稱。
4. >：消息：消息的具體內容。

在有些情況下，可以設置syslog，使其在把日誌信息記錄到文件的同時將日誌信息發送到打印機進行打印，這樣無論網絡入侵者怎麽修改日誌都不能清除入侵的痕跡。syslog日誌服務是一個常會被攻擊的顯著目標，破壞了他將會使管理員難以發現入侵以及入侵的痕跡，因此要特別註意監控其守護進程以及配置文件。

>用戶日誌

在wtmp、utmp、lastlog等日誌文件中，保存了系統用戶登錄，退出等相關事件的事件消息。但是這些文件都是二進制的數據文件，不能直接使用tail、less等文本查看工具進程瀏覽，需要使用who、w、users、last和ac等用戶查詢命令來獲取日誌信息。

這裏就不再演示。

3、程序日誌

在Linux系統中，還有相當一部分應用程序並沒有使用syslog服務來管理日誌。而是由程序自己維護日誌記錄。例如，httpd網站服務程序使用兩個日誌文件access_log和error_log，一般存放在"/var/log/httpd“目錄中，分別記錄客戶訪問事件，錯誤事件，而FTP服務程序可以將與文件上傳，下載事件相關的消息記錄在xferlog文件中。由於不同應用程序的日誌記錄格式差別較大，並沒有嚴格使用統一的格式，這裏不詳解！

特例：服務器日誌分布管理策略：

鑒於日誌數據資料的重要性，對於系統運行過程中產生的各種日誌文件，必須采用有針對性的管理策略，以確保日誌數據的準確性、安全性和真實性。一般來說，可以從以下幾個方面進行考慮。

>：日誌備份和歸檔：日誌文件也是重要的數據資料，同樣需要進行備份和歸檔。

>：延長日誌保存期限：在存儲空間富裕的情況下，日誌數據保留的時間應盡可能長。

>：控制日誌訪問權限：日誌數據中可能會包含各類敏感信息，如：賬號、口令等。所以需要嚴格控制其訪問權限。

>：集中管理日誌：使用集中的日誌服務器管理各服務器發送的日誌記錄等。其好處在於方便對日誌的收集、整理和分析，杜絕意外的丟失、惡意篡改或刪除等。

eg：服務器A（IP地址為173.17.17.3/24），用於集中保存日誌記錄。

將客戶機B（IP地址為173.17.17.11/24）中crond服務產生的日誌記錄，統一保存到服務器A中的“/var/log/cron”文件中。

• 設置日誌服務器A

在日誌服務器A中，需要編輯syslog日誌服務的啟動參數配置文件"/etc/sysconfig/syslog"，將SYSLOGD_OPTIONS變量的內容改為“-r -x -m 0”即可。其中"-r"選項表示允許接受其他主機發送過來的日誌記錄，"-x"選項表示不進程DNS域名解析，"-m"表示記錄日誌的時間標記間隔（設為0禁用該功能），這些信息可以通過查看syslogd程序的man手冊頁獲得

*：修改日誌服務器A的“/etc/sysconfig/syslog”文件，添加集中管理配置參數“-r”，並重啟syslog服務。

1. vi /etc/sysconfig/syslog //修改SYSLOGD_OPTIONS行SYSLOGD_OPTIONS="-r -x -m 0"
2. service syslog restart

• 設置客戶機B

在客戶機B中，需要修改"/etc/syslog.conf"配置文件，設置將cron計劃任務的日誌消息寫入到服務器A的"/var/log/cron"文件中。指定寫入日誌的主機地址時，[email protected]

*：修改客戶機B的"/etc/syslog.conf"文件，找到cron日誌的配置行，[email protected]，並重啟syslog服務。

1. vi /etc/syslog.conf
2. cron.* @173.17.17.3
3. service syslog restart

• 驗證日誌集中管理功能

在客戶機B中執行"crontab -e"命令，隨便編寫一條計劃任務信息並保存退出，然後查看本機中的"/var/log/cron"日誌文件，將發現沒有任何新的記錄。

4、系統啟動類故障排除

在Linux系統的啟動過程中，涉及到哦MBR主引導記錄、GRUB啟動菜單、系統初始化配置文件、分區掛載配置文件等各方面，其中任何一個環節出現故障都可能會導致系統啟動的失常，因此一定要註意做好相關文件的備份功能。下面是一些系統啟動類的故障情況:

> MBR扇區故障

MBR引導記錄位於物理硬盤的第一個扇區（512個字節），該扇區又稱為主引導扇區（MBR扇區），除了包含系統引導程序的部分數據以外，還包含了整個硬盤的分區表記錄。當主引導扇區發送故障時，將可能無法進入主引導菜單，或者因無法找到正確的分區位置而無法加載系統，通過該硬盤引導主機時很可能進入黑屏狀態。

下面將介紹對MBR扇區進行備份、破壞、修復的過程，嘿嘿！

>：備份MBR扇區數據

由於MBR扇區包含了整個硬盤的分區表記錄，因此該扇區的備份文件必須存在其他的存儲設備中，否則在恢復時將無法讀取帶備份文件。

使用dd命令將第1塊硬盤（sda）的MBR扇區備份到第2塊硬盤的sdb1分區中（掛載到/backup目錄）

1. mkdir /backup
2. mount /dev/sdb1 /backup
3. dd if=/dev/sda of=/backup/sda.mbr.bak bs=512 count=1

>：模擬MBR扇區故障

仍然使用dd命令，我們人為將MBR扇區的記錄覆蓋，以便模擬出MBR故障、

1. dd if=/dev/zero of=/dev/sda bs=512 count=1

完成上述操作後重啟系統，將會出現"Operating system not found "的提示信息，表示無法找到可能的操作系統，因此無法啟動主機。

> 從備份文件中恢復MBR扇區數據

由於MBR扇區被破壞以後，已經無法再從該硬盤啟動系統，所以需要使用其他硬盤中的操作系統進行引導，或者直接使用RHEL5系統的安裝光盤進行引導。不管使用哪種方式，目地都是相同的：獲得一個可以執行命令的Shell環境，以變從備份文件中恢復MBR扇區中的數據，

以使用RHEL5安裝光盤引導為例，當出現安裝向導的：“boot”提示符時，在後邊輸入“linux rescue‘並回車，將以”急救模式“引導光盤中的Linux系統。之後一次按回車鍵接受默認的語言、鍵盤合適，提示是否配置網卡時一般選擇”No’，然後系統會自動查看硬盤中的Linux分區並嘗試將其掛載到"/mnt/sysimage"目錄（選擇“Continue”確認並繼續）。接下需要特別輸液椅：當出現是否初始化磁盤的警告窗口時如：

一定要選擇"No"，以免對硬盤數據造成進一步損壞。

最好選擇“OK”確認後進入到帶"sh-3.1#"提示符的Bash Shell環境，只要執行相應的命令掛載保存有備份文件的硬盤文件（sdb1），並將數據恢復到硬盤"/dev/sda"中即可。需要註意的是，當前使用的系統環境是光盤中的Linux目錄結構。

*>：確認第1塊硬盤的分區情況（已無法獲得有效分區表信息，並恢復MBR扇區的數據）。

1. fdisk -l /dev/sda

1. mkdir /tmpdir
2. mount /dev/sdb1 /tmpdir
3. dd if=/tmpdir/sda.mbr.bak of=/dev/sda bs=512 count=1 //恢復備份數據

完成恢復操作以後，執行"reboot"重啟主機即可（註意取出RHEL5的安裝光盤）。

5、GRUB引導故障

GRUB是大多數Linux系統默認使用的引導程序，可以通過啟動菜單的方式選擇進入不同的操作系統（如果有的話）。當"/boot/grub.conf‘配置文件丟失，或者關鍵配置出現錯誤，或者MBR記錄中的引導程序遭到破壞時，Linux主機啟動後可能會出現"grub>“的提示符，無法完成進一步的系統啟動過程。

如果在該提示符，可以進行編輯，通過輸入對應的引導命令（可以參考”/boot/grub/grub,conf"文件中的配置），再執行"boot‘命令也可以進行引導Linux系統。

eg>：通過在"grub>"環境中手動輸入引導命令啟動Linux系統。

1. grub>root (hd0,0)
2. grub>kernel/vmlinux-2.6.18-8.e15 ro root=/dev/VolGroup00/LogVo100 rhgb quiet
3. grub>inited /initrd-2.6.18-8.e15.img
4. grub>boot

之後的啟動成功與正常啟動RHEL5系統的過程是一模一樣的。登錄進入系統以後，需要找到配置文件"/boot/grub/grub.conf‘，並修復其中的錯誤，或者直接重建該文件。具體內容可以參考其他正常主機的同名文件。

.>>>>>>>>>：查看grub.conf啟動菜單配置文件的主要內容。 grep -v "^#" /boot/grub/grub.conf

其中，各主要配置項的含義說明：

>：title：指定在啟動菜單中顯示的操作系統名稱。

>：root：指定包含內核等引導文件的/boot分區所在的位置。

>：kernel：指定內核文件所在的位置，內核加載時權限為只讀"ro"，並通過"root="指定根分區設備文件的位置。

>：initrd：指定啟動內核所使用的臨時系統鏡像文件所在的位置。

由於在"grub>"環境中使用的命令較為復雜，而且一般難以記得相關的命令選項，內核加載參數等。因此用戶可以采用另一種修復辦法，同樣使用RHEL5的安裝光盤進入急救模式，如果分區表並未被破壞，則急救模式將會找到硬盤中的Linux根分區，並將其掛載到光盤目錄結構中的"/mnt/sysimage/"文件夾中。

進入"sh-3.1"的Shell環境以後，執行"chroot /mnt/sysimage"命令可以將目錄結構切換到待修復的Linux系統中。然後重新建立新的grub.conf配置文件即可。

eg：確認待修復的Linux系統分區的掛載情況，並重建grub.conf文件。

1. chroot /mnt/sysimage //切換到待修復的Linux系統根環境。
2. mount
3. .....省略部分內容
4. vi /boot/grub/grub.conf //重建grub.conf文件，內容就不寫了
5. exit //退出chroot環境
6. exit //退出sh-3.1環境，系統會自動重啟

在上例中，若為執行"chroot /mnt/sysimage"命令，則重新建立的grub.conf配置文件應該位於"/mnt/sysimage/boot/grub/grub.conf"

如果是MBR扇區中的引導程序出現損壞，可能在重建grub.conf配置文件後仍然無法成功啟動系統，這時候可以在救援模式的Shell環境重新安裝grub

eg：進入待修復的Linux系統根環境，重新將grub引導程序安裝到第一塊硬盤（sda）中的MBR扇區中。

1. chroot /mnt/sysimage
2. grub-install /dev/sda
3. exit
4. exit

上述方法同樣適用於在Linux主機中那種Windows系統（不覆蓋Linux系統）後導致Linux系統無法啟動的情況。因為i對於使用雙操作系統的主機，後安裝的Windows系統將使用自己的引導數據覆蓋MBR扇區中的記錄，導致開機後不再出現GRUB菜單從而無法進入Linux系統。如果是後安裝Linux系統，GRUB程序將會自動識別硬盤中的Window系統並將其加載到GRUB菜單配置中。

> /etc/inittab文件丟失

"/etcinittab"文件是系統初始化進程init的配置文件，當該文件被誤刪或者存在錯誤配置時，可能導致無法啟動系統。丟失"/etc/inittab"文件後，啟動後將會出現"INIT：No inittab file found"的錯誤提示信息。

這類故障同樣可以在RHEL5安裝光盤的急救模式下進行修復。如果文件配置錯誤，則進行糾正或者從備份文件中進行恢復即可。默認情況下，如果並未使用chroot命令切換環境，則需要修改的文件"/mnt/sysimage/etc/inittab"。

若inittab文件已經丟失，且沒有可用的備份。則需要從RHEL5的光盤目錄中重新安裝initscript軟件包。

eg：在急救模式的"sh-3.1#"環境中掛載RHEL5光盤設備，並重新安裝initscript軟件包，結合rpm 命令的"--replacepkgs"選項用於替代現有文件。

1. chroot /mnt/sysimage
2. mount /dev/hdc /media/cdrom
3. rpm -vhi --replacepkgs /media/cdrom/Server/initscripts-8.45.14.EL.i386.rpm

在急救模式的Shell環境中通常不再保留cdrom連接文件，而直接通過設備文件"/dev/hdc‘使用光盤。安裝完畢重啟系統即可。

> /etc/fstab文件丟失

"/etc/fstab"配置文件決定了Linux系統在啟動後如何加載各分區，例如根分區"/"、"/boot"分區等，若這些分區無法掛載，系統也就無法成功啟動。丟失"/etc/fstab"文件後，啟動時將會出現如下錯誤提示信息。

同樣使用RHEL5的安裝光盤進入急救模式的Shell環境中，由於缺少fstab文件，光盤系統將無法找到待修復的Linux分區，因此必須通過手動的方式查找並掛載根分區，然後重建fstab配置文件後重啟系統即可。

eg：在急救模式的Shell環境中掃描邏輯卷組，激活邏輯卷，以便找到根分區設備，然後手動掛載根分區，並重建fstab配置文件。

1. lvm vgscan //查找邏輯卷
2. lvm vgchange -ay /dev/VolGroup00 //激活找到的邏輯卷
3. mkdir /tmpdir
4. mount /dev/VolGroup00/LogVol00 /tmpdir //掛載根分區到/tmpdir目錄
5. vi /tmpdir/etc/fstab //重建fstab配置文件，或直接復制備份的文件

6、遺忘root用戶的密碼

>：通過單用戶模式重設root賬號的密碼（不再說明）；

>：通過急救模式重設root賬號的密碼

若使用RHEL5的安裝光盤進入急救模式的Shell環境，則只需切換到待修復Linux系統的根目錄環境，直接執行"passwd root"命令重設root用戶的密碼即可；或者修改 "/etc/shadow"文件，將root用戶的密碼字段清空，重啟，正常進入系統再修改密碼。

eg：在急救模式中，切換到待修復的Linux根分區環境，修改root賬號的密碼。

1. chroot /mnt/sysimage
2. passwd root
3. ....

轉自http://os.51cto.com/art/201405/438510.htm

linux系統故障分析與排查