<em id="pn7p8"><acronym id="pn7p8"><u id="pn7p8"></u></acronym></em>

    <th id="pn7p8"></th>

    <button id="pn7p8"></button>

      <dd id="pn7p8"></dd>
      <progress id="pn7p8"><track id="pn7p8"></track></progress>

      Linux培訓
      達內IT學院

      400-111-8989

      出了Linux故障怎么辦?有沒有簡單的方法解決?

      • 發布:Linux培訓
      • 來源:Linux培訓常見問題匯總
      • 時間:2017-07-21 16:01

      與windows系統一樣,linux操作系統也會存在很多問題和故障,很多linux新手都害怕故障,面對出現的問題顯得無可奈何,更有甚者,由此放棄了linux,其實,我們不應該懼怕問題,學習就是一個發現問題與解決問題的過程,只要掌握了解決問題的基本思路,一切故障都會迎刃而解,當然前提是我們已經具備了解決問題的思路和扎實的知識功底。

      作為一名合格的linux系統管理員,一定要有一套清晰、明確的解決故障思路,當問題出現時,才能迅速定位、解決問題,這里給出一個處理問題的一般思路:

      ——重視報錯提示信息:每個錯誤的出現,都是給出錯誤提示信息,一般情況下這個提示基本定位了問題的所在,因此一定要重視這個報錯信息,如果對這些錯誤信息視而不見,問題永遠得不到解決。

      ——查閱日志文件:有時候報錯信息只是給出了問題的表面現象,要想更深入的了解問題,必須查看相應的日志文件,而日志文件又分為系統日志文件(/var/log)和應用的日志文件,結合這兩個日志文件,一般就能定位問題所在。

      ——分析、定位問題:這個過程是比較復雜的,根據報錯信息,結合日志文件,同時還要考慮其它相關情況,最終找到引起問題的原因。

      ——解決問題:找到了問題出現的原因,解決問題就是很簡單的事情了。

      從這個流程可以看出,解決問題的過程就是分析、查找問題的過程,一旦確定問題產生的原因,故障也就隨之解決了。

      下面我們來看看這些問題的解法和做法:

      問題1:Read-only file system 錯誤與解決方法

      解析:出現這個問題的原因有很多種,可能是文件系統數據塊出現不一致導致的,也可能是磁盤故障造成的,主流ext3/ext4文件系統都有很強的自我修復機制,對于簡單的錯誤,文件系統一般都可以自行修復,當遇到致命錯誤無法修復的時候,文件系統為了保證數據一致性和安全,會暫時屏蔽文件系統的寫操作,講文件系統 變為只讀,今兒出現了上面的“read-only file system”現象。

      手工修復文件系統錯誤的命令式fsck,在修復文件系統前,最好卸載文件系統所在的磁盤分區

      # umount /www/data Umount : /www/data: device is busy

      提示無法卸載,可能是這個磁盤中還有文件對應的進程在運行,檢查如下:

      # fuser –m /dev/sdb1 /dev/sdb1: 8800

      接著檢查一下8800端口對應的什么進程,

      # ps –ef |grep 8800

      檢查后發現時apache沒有關閉,停止apache

      # /usr/local/apache2/bin/apachectl stop # umount /www/data # fsck –V –a /dev/sdb1 # mount /dev/sdb1 /www/data

      問題2:“Argument list too long”錯誤與解決方法

      # crontab –e

      編輯完后保存退出后,報錯no space left on device

      根據上面的報錯了解到是磁盤空間滿了,那么首先是檢查磁盤空間,

      # df –h

      查看到是/var磁盤分區空間已經達到100%,至此定位了問題所在。是/var磁盤空間飽滿導致,因為crontab會在保存時將文件信息寫到/var目錄下面,然而這個磁盤沒有空間了,所以報錯。

      接著通過命令du –sh * 命令檢查/var目錄下面的所有文件或者目錄的大小,發現/var/spool/clientmqueue目錄占用了/var整個分區大小的90%,那么/var/spool/clientmqueue目錄下的文件都是怎么產生的,能否刪除,基本上都是郵件信息,可以刪除

      # rm * /bin/rm :argument list too long

      當在linux 系統中試圖傳遞太多參數給一個命令時,就會出現“argument list too long ”錯誤,這是linux系統一直以來都有的限制,查看這個限制可以通過命令“getconf ARG_MAX”來實現,

      # getconf ARG_MAX

      # more /etc/issue 查看版本

      解決方法:

      1、

      # rm [a-n]* -rf # rm [o-z]* -rf

      2、使用find命令來刪除

      # find /var/spool/clientmqueue –type f –print –exec rm –f {} \;

      3、通過shell腳本

      #/bin/bash RM_DIR=’/var/spool/clientmqueue’ cd $RM_DIR for I in `ls` do rm –f $i done

      4、重新編譯內核

      需要手動增加內核中分配給命令行參數的頁數,打開kernel source 下面的include/linux/binfmts.h文件,找到如下行:

      #denfine MAX_ARG_PAGES 32

      將32改為更大的值,例如64或者128,然后重新編譯內核

      問題3:inode耗盡導致應用故障

      客戶的一臺Oracle數據庫如武器在關機重啟后,Oracle監聽無法啟動,提示報錯 Linux error : No space left on device

      從輸出信息看出來是因為磁盤耗盡導致監聽無法啟動,因為Oracle在啟動監聽時需要創建監聽日志文件,于是首先查看磁盤空間使用情況

      # df –h

      從磁盤輸出信息可知,所有的分區磁盤空間都還有剩余不少,而Oracle監聽寫日志的路徑在/var分區下,/var下分區空間足夠。

      解決思路:

      既然錯誤提示語磁盤空間有關,那就深入研究關于磁盤空間的問題,在linux系統中對磁盤空間的占用分為三個部分:第一個是物理磁盤空間,第二個是inode節點所占用的磁盤空間,第三個是linux用來存放信號量的空間,而平時接觸較多的是物理磁盤空間。既然不是物理磁盤空間的問題,接著就檢查是否是inode節點耗盡的問題,通過執行命令“df -i”查看可用的inode節點。由輸出結果看出確實是因為inode耗盡導致無法寫入文件。

      可以通過下面的命令查看某個磁盤分區inode的總數

      # dumpe2fs –h /dev/sda3 |grep ‘Inode count’

      每個inode都有一個號碼,操作系統用inode號碼來區分不同的文件,通過‘ls -i’命令可以查看文件名對應的inode號

      如果要查看這個文件更詳細的inode信息,可以通過stat命令來實現

      # stat install.log

      解決問題

      # find /var/spool/clientmqueue/ -name “*” –exec rm –rf {} \;

      問題4:文件已經刪除,但是空間沒有釋放的原因

      運維監控系統發來通知,報告一臺服務器空間滿了,登陸服務器查看,根分區確實滿了,這里先說一下服務器的一些刪除策略,由于linux沒有回收站功能,所以線上服務器上所有要刪除的文件都會先移到系統/tmp目錄下,然后定期清除/tmp目錄下的數據。這個策略本身沒有什么問題,但是通過檢查發現這臺服務器的系統分區中并沒有單獨劃分/tmp分區,這樣/tmp下的數據其實占用根分區的空間,既然找到了問題,那么刪除/tmp目錄下一些占用空間較大的數據文件即可。

      # du –sh /tmp/* | sort –nr |head -3

      通過命令發現在/tmp目錄下有個66G大小的文件access_log,這個文件應該是apache產生的訪問日志文件,從日志大小來看,應該是很久沒有清理的apache日志文件了,基本判定是這個文件導致的根空間爆滿,在確認此文件可以刪除后,執行如下刪除命令,

      # rm /tmp/access_Iog # df –h

      從輸出來看,根分區空間仍然沒有釋放,這是怎么回事

      一般來說不會出現刪除文件后空間不釋放的情況,但是也存在例外,比如文件進程鎖定,或者有進程一直在向這個文件寫數據,要理解這個問題,就需要知道linux下文件的存儲機制和存儲結構。

      一個文件在文件系統中存放分為兩個部分:數據部分和指針部分,指針位于文件系統的meta-data中,在將數據刪除后,這個指針就從meta-data中清除了,而數據部分存儲在磁盤中。在將數據對應的指針從meta-data中清除后,文件數據部分占用的空間就可以被覆蓋并寫入新的內容,之所以出現刪除access_log文件后,空間還沒有釋放,就是因為httpd進程還在一直向這個文件寫入內容,導致雖然刪除了access_Ilog文件,但是由于進程鎖定,文件對應的指針部分并未從meta-data中清除,而由于指針并未刪除,系統內核就認為文件并未被刪除,因此通過df命令查詢空間并未釋放。

      問題排查:

      既然有了解決思路,那么接下來看看是否有進程一直在向access_log文件中寫入數據,這里需要用到linux下的losf命令,通過這個命令可以獲取一個仍然被應用程序占用的已刪除文件列表

      # lsof |grep delete

      從輸出可以看出,/tmp/access_log文件被進程httpd鎖定,而httpd進程還一直向這個文件寫入日志數據,最后一列的‘deleted’狀態說明這個日志文件已經被刪除,但是由于進程還在一直向此文件寫入數據,因此空間并未釋放。

      解決問題:

      到這里問題就基本排查清楚了,解決這一類問題的方法有很多,最簡單的方法就是關閉或者重啟httpd進程,當然重啟操作系統也可以。不過這些并不是最好的辦法,對待這種進程不停對文件寫日志的操作,要釋放文件占用的磁盤空間,最好的方法是在線清空這個文件,具體可以通過如下命令完成:

      # echo “ ” >/tmp/access_log

      通過這種方法,磁盤空間不但可以馬上釋放,也可以保障進城繼續向文件寫入日志,這種方法經常用于在線清理apache /tomcat/nginx等web服務產生的日志文件。

      問題5:“too many open files”錯誤與解決方法

      問題現象:這是一個基于java的web應用系統,在后臺添加數據時提示無法添加,于是登陸服務器查看tomcat日志,發現如下異常信息,java.io.IOException: Too many open files

      通過這個報錯信息,基本判斷是系統可以用的文件描述符不夠了,由于tomcat服務室系統www用戶啟動的,于是以www用戶登陸系統,通過ulimit –n 命令查看系統可以打開最大文件描述符的數量,輸出如下:

      $ ulimit –n 65535

      可以看到這臺服務器設置的最大可以打開的文件描述符已經是65535了,這么大的值應該夠用了,但是為什么提示這樣的錯誤呢

      解決思路,這個案例涉及ulimit命令的使用

      在使用ulimit時,有以下幾種使用方法:

      1、 在用戶環境變量中加入

      如果用戶使用的是bash,那么可以在用戶目錄的環境變量文件.bashrc或者.bash_profile中加入“ulimit –u128”來限制用戶最多可以使用128個進程

      2、 在應用程序的啟動腳本中加入

      如果應用程序是tomcat,那么可以再tomcat的啟動腳本startup.sh中加入‘ulimit –n 65535’來限制用戶最多可以使用65535個文件描述符

      3、 直接在shell命令終端執行ulimit命令

      這種方法的資源限制僅僅在執行命令的終端生效,在退出或者和關閉終端后,設置失效,并且這個設置不影響其他shell終端

      解決問題:

      在了解ulimit知識后,接著上面的案例,既然ulimit設置沒有問題,那么一定是設置沒有生效導致的,接下來檢查下啟動tomcat的www用戶環境變量是否添加ulimit限制,檢查后發現,www用戶并無ulimit限制。于是繼續檢查tomcat啟動腳本startup.sh文件是否添加了ulimit限制,檢查后發現也沒有添加。最后考略是否將限制加到了limits.conf文件中,于是檢查limits.conf文件,操作如下

      # cat /etc/security/limits.conf |grep www www soft nofile 65535 www hard ofile 65535

      從輸出可知,ulimit限制加在limits.conf文件中,既然限制已經添加了,配置也沒有什么錯,為何還會報錯,經過思考,判斷只有一種可能,那就是tomcat的啟動時間早于ulimit資源限制的添加時間,于是首先查看下tomcat啟動時間,操作如下

      # uptime Up 283 days # pgrep –f tomcat 4667 # ps –eo pid,lstart,etime|grep 4667 4667 Sat Jul 6 09;33:39 2013 77-05:26:02

      從輸出可以看出,這臺服務器已經有283沒有重啟了,而tomcat是在2013年7月6日9點啟動的,啟動了將近77天,接著繼續看看limits.conf文件的修改時間,

      # stat /etc/security/limits.conf

      通過stat命令清除的看到,limits.conf文件最后的修改時間是2013年7月12,晚于tomcat啟動時間,清楚問題后,解決問題的方法很簡單,重啟一下tomcat就可以了。

      問題6:(Apache常見錯誤故障案例)”no space left on device “錯誤與解決方法

      錯誤現象: 客戶反映在執行”apachectl start “啟動Apache是無報錯信息,但是還是不能訪問網頁,客戶的網站是基于Apache+PHP+mysql 的在線交易平臺,聽到客戶描述的現象后,第一反應就是防火墻屏蔽了HTTP端口或selinux的問題,于是登陸服務器查看相關信息,從輸出信息可以看出,防火墻所有的策略都處于開放狀態,并未做出任何限制,而selinux也處于關閉狀態,應該不是防火墻導致的。既然不是防火墻導致的,那么看看httpd進程是否存在及httpd端口是否正常啟動

      # ps –ef |grep httpd|grep –v “grep” |wc –l 0 # netstat –nultp |grep 80 # /usr/local/apache2/bin/apachectl start # ps –ef |grpe httpd |grep –v “grep” |wc –l 0

      這個操作首先查看了服務器上的httpd進程,發現并沒有HTTP進程運行,同時httpd對應的端口80也并沒有啟動,于是重啟Apache,在啟動Apache的過程中并沒有報錯,啟動完成后發現仍然HTTP進程沒有運行,由此看來,應該是Apache內部出現了問題

      解決思路:

      在判斷Apache問題后,首先要看的就是Apache的啟動日志,在查看Apache的error日志后,發現了一個可疑輸出,內容為:

      No space left on device : mod_rewrite: could not create rewrite_log_lock configuration failed

      出了Linux故障找不到方法?看大牛簡單、樸實的解決思路

      看到這個錯誤提示,感覺應該是磁盤空間耗盡導致,于是趕緊查看系統系統所有磁盤分區,結果發現所有磁盤分區都還有很多可用空間,這就奇怪了,在前面的案例介紹中,詳細介紹了linux對磁盤空間的占用分為三個部分:物理磁盤、inode節點磁盤空間和信號量磁盤空間。通過檢查服務器的物理磁盤空間,發現仍有很多剩余,因此排除物理空間的問題,接著通過”df -i”命令查看系統可用的inode節點,發現每個分區可以用的inode還有很多,這樣inode節點問題也被排除了,那么應該是信號量磁盤空間耗盡導致的。

      這里簡單的介紹下linux信號量相關知識。信號量是一種鎖機制,用于協調進程之間互斥的訪問臨界資源,以確保某種共享資源不被多個進程同時訪問。Linux系統的信號量是用于進程間通信的。它有兩種標準實現,分別是POSIX及System v ,現在大多數linux系統都實現了這兩種標準,這兩種標準都可用于進行線程間的通信,只是系統調用方式略有不同。

      System v 信號量通過系統調用semget來創建,通過linux命令ipcs即可顯示進程間通信用的system v 類型信號量及共享內存。

      Posix 信號量可用于線程和進程間通信,并可分為有名和無名兩種,也可以理解為是否保存在磁盤上。

      解決問題:

      # cat /proc/sys/kernel/sem # ipcs –s |grep daemon

      Daemon是啟動Apache進程的用戶,默認是daemon,也可能是nobody用戶,根據實際環境而定。解決信號量耗盡的方法很簡單,通過ipcrm命令清除即可,最簡單方法是執行如下命令組合:

      # ipcs –s |grep nobody |perl –e ‘while (<STDIN>) { @a=split(/\s+/);print `ipcrmsem $a[1]` }’

      問題7:linux系統無法啟動的解決方法

      這是linux最常見的故障,系統在掉電,以及執行配置更新、軟件升級、內核升級后都有可能導致系統無法啟動,究其原因,可能有很多種,常見的如下幾種:

      1) 文件系統破壞,一般是linux的根分區文件系統遭到破壞,導致系統無法啟動,這種情況一般是有系統突然掉電或者非法關機引起的。

      2) 文件系統配置不當,比如/etc/inittab文件、/etc/fstab文件等配置錯誤或丟失,導致系統錯誤,無法啟動,這種情況一般是執行配置更新時人為導致的

      3) Linux內核文件丟失或者崩潰,從而導致系統無法引導啟動,這種情況可能是內核升級錯誤或者內核存在bug引起的

      4) 系統引導程序出現問題,比如grub丟失或者損壞,導致系統無法引導啟動,這種情況一般是人為修改錯誤或者文件系統故障導致的。

      5) 系統硬件故障,比如主板、電源、硬盤等出現問題,導致linux系統無法正常啟動,這種情況基本都是由于服務器硬件問題導致的。

      問題8:文件系統破壞導致系統無法啟動

      Checking root filesystem /dev/sda6 contains a file system with errors, check forced An error occurred during the file system check

      這個錯誤可以看出,操作系統/dev/sda6分區文件系統出現了問題,這個問題發生的機率很高,通常引起這個問題的原因主要是系統突然斷電,引起文件系統結構不一致,一般情況下,解決此問題的方法是采用fsck命令,進行強制修復。

      # umount /dev/sda6 # fsck.ext3 –y /dev/sda6

      問題9:訪問權限問題

      當某些服務不能訪問的時候,一定要檢查是否被linux本機防火墻iptables屏蔽了,可以通過iptables –L –n 命令檢查iptables的配置策略。

      # iptables –L –n # iptables –A INPUT –i eth0 –p tcp --dport 80 –j ACCEPT # iptables –A OUTPUT –p tcp --sport 80 –m state –state ESTABLISHED –j ACCEPT

      預約申請免費試聽課

      填寫下面表單即可預約申請免費試聽!怕錢不夠?可就業掙錢后再付學費! 怕學不會?助教全程陪讀,隨時解惑!擔心就業?一地學習,可全國推薦就業!

      上一篇:達內Linux培訓怎么樣?達內Linux培訓課程優勢
      下一篇:Linux上如何安裝Bugfree系統?
      • 掃碼領取資料

        回復關鍵字:視頻資料

        免費領取 達內課程視頻學習資料

      • 視頻學習QQ群

        添加QQ群:1143617948

        免費領取達內課程視頻學習資料

      Copyright ? 2021 Tedu.cn All Rights Reserved 京ICP備08000853號-56 京公網安備 11010802029508號 達內時代科技集團有限公司 版權所有

      選擇城市和中心
      黑龍江省

      吉林省

      河北省

      湖南省

      貴州省

      云南省

      廣西省

      海南省

      高清特黄a大片,日本真人真做爰,特级做人爱C级,免费a级毛片 百度 好搜 搜狗
      <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>