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

日志分析及管理

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

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

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

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

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

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

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

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

>/var/log/messages：記錄Linux內核消息及各種應用程序的公共日志信息，包括啟動、IO錯誤、網絡錯誤、程序故障等。對于未使用獨立日志文件的應用程序或服務，一般都可以從該文件獲得相關的事件記錄信息。 
>/var/log/cron：記錄crond計劃任務產生的事件消息。 
>/varlog/dmesg：記錄Linux系統在引導過程中的各種事件信息。 
>/var/log/maillog：記錄進入或發出系統的電子郵件活動。 
>/var/log/lastlog：最近幾次成功登錄事件和最后一次不成功登錄事件。 
>/var/log/rpmpkgs：記錄系統中安裝各rpm包列表信息。 
>/var/log/secure：記錄用戶登錄認證過程中的事件信息。 
>/var/log/wtmp：記錄每個用戶登錄、注銷及系統啟動和停機事件。 
>/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內核中，根據日志消息的重要程度不同，將其分為不同的優先級別（數字等級越小，優先級越高，消息越重要）。

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

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

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

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

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

在有些情況下，可以設置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服務。

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

• 設置客戶機B

在客戶機B中，需要修改"/etc/syslog.conf"配置文件，設置將cron計劃任務的日志消息寫入到服務器A的"/var/log/cron"文件中。指定寫入日志的主機地址時，采用“@173.17.17.3”的格式即可。

*：修改客戶機B的"/etc/syslog.conf"文件，找到cron日志的配置行，將日志發送位置改為“@173.17.17.3”，并重啟syslog服務。

vi /etc/syslog.conf 
cron.*                         @173.17.17.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目錄）

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

>：模擬MBR扇區故障

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

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扇區的數據）。

fdisk -l /dev/sda 

mkdir /tmpdir 
mount /dev/sdb1 /tmpdir 
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系統。

grub>root (hd0,0) 
grub>kernel/vmlinux-2.6.18-8.e15 ro root=/dev/VolGroup00/LogVo100 rhgb quiet 
grub>inited /initrd-2.6.18-8.e15.img 
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文件。

chroot /mnt/sysimage               //切換到待修復的Linux系統根環境。 
mount 
.....省略部分內容 
vi /boot/grub/grub.conf             //重建grub.conf文件，內容就不寫了 
exit                                        //退出chroot環境 
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扇區中。

chroot /mnt/sysimage 
grub-install /dev/sda 
exit 
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"選項用于替代現有文件。

chroot /mnt/sysimage 
mount /dev/hdc /media/cdrom 
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配置文件。

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

6、遺忘root用戶的密碼

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

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

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

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

chroot /mnt/sysimage 
passwd root 
....