Linux運維常見故障排查和處理的技巧彙總（資源）

時間 2019-11-17

標籤 linux 常見故障排查處理技巧彙總資源欄目 Linux 简体版

原文原文鏈接

第一：常見問題解決集錦css

1.shell腳本不執行
    問題：某天研發同事找我說幫他看看他寫的shell腳本，死活不執行，報錯。我看了下，腳本很簡單，也沒有常規性的錯誤，報「:badinterpreter:Nosuchfileordirectory」錯。
    看這錯，我就問他是否是在windows下編寫的腳本，而後在上傳到linux服務器的……果真。
    緣由：在DOS/windows裏，文本文件的換行符爲rn，而在*nix系統裏則爲n，因此DOS/Windows裏編輯過的文本文件到了*nix裏，每一行都多了個^M。
    解決：
    1）從新在linux下編寫腳本；
    2）vi:%s/r//g:%s/^M//g（^M輸入用Ctrl+v,Ctrl+m）
    附：sh-x腳本文件名，能夠單步執行並回顯結果，有助於排查複雜腳本問題。html

2.crontab輸出結果控制前端

    問題：
    /var/spool/clientmqueue目錄佔用空間超過100G
    緣由：
    cron中執行的程序有輸出內容，輸出內容會以郵件形式發給cron的用戶，而sendmail沒有啓動因此就產生了/var/spool/clientmqueue目錄下的那些文件，日積月累可能撐破磁盤。
    解決：
    1）直接手動刪除：ls | xargs rm -f；
    2）完全解決：在cron的自動執行語句後加上>/dev/null2>&1mysql

  3.telnet很慢/ssh很慢
    問題：
    某天研發同事說10.50訪問10.52 memcached服務異常，讓咱們檢查下看網絡/服務/系統是否有異常。檢查發現系統正常，服務正常，10.50 ping 10.52也正常，但10.50 telnet10.52很慢。同時發現該機器的namesever是不起做用的。
    緣由：
    because your PC doesn’t doareverse DNS look up on your IP then…when you telnet/ftp into your linux box , it’ll doadns look up on you。
    解決：
    1)修改/etc/hosts使hostname和ip對應；
    2）在/etc/resolv.conf註釋掉nameserver或者找一個「活的」nameserver。linux

  4.Read-onlyfilesystem
    問題：
    同事在mysql裏建表建不成功，提示以下：
    mysql>createt able wos on test(colddname1char(1));
    ERROR1005(HY000):Can’t creat etable ‘wosontest’ (errno:30）
    經檢查mysql用戶權限以及相關目錄權限沒問題；用perror30提示信息爲：OS error code 30 : Read-only filesystem
    可能緣由：
    1）文件系統損壞；
    2）磁盤又壞道；
    3）fstab文件配置錯誤，如分區格式錯誤錯誤(將ntfs寫成了fat)、配置指令拼寫錯誤等。
    解決：
    1）因爲是測試機，重啓機器後恢復；
    2）網上說用mount可解決。ios

  5.文件刪了磁盤空間沒釋放
    問題：
    某天發現某臺機器df -h已用磁盤空間爲90G，而du -sh /*顯示全部使用空間加起來才30G，囧。
    緣由：
    可能某人直接用rm刪除某個正在寫的文件，致使文件刪了但磁盤空間沒釋放的問題
    解決：
    1）最簡單重啓系統或者重啓相關服務。
    2）幹掉進程
    /usr/sbin/ lsof | grep deleted
    ora25575data33uREG65,654294983680/oradata/DATAPRE/UNDOTBS009.dbf(deleted)
    從lsof的輸出中，咱們能夠發現pid爲25575的進程持有着以文件描述號（fd）爲33打開的文件/oradata/DATAPRE/UNDOTBS009.dbf。在咱們找到了這個文件以後能夠經過結束進程的方式來釋放被佔用的空間：echo>/proc/25575/fd/33
    3）刪除正在寫的文件通常用cat/dev/null>filegit

  6.find文件提高性能
    問題：
    在tmp目錄下有大量包含picture_*的臨時文件，天天晚上2:30對一天前的文件進行清理。以前在crontab下跑以下腳本，可是發現腳本效率很低，每次執行時負載猛漲，影響到其餘服務。
    #!/bin/sh
    find /tmp -name 「picture_*」 -mtime +1 -exec rm-f {};
    緣由：
    目錄下有大量文件，用find很耗資源。
    解決：
    #!/bin/sh
    cd /tmp
    time=`date -d 「2 day ago」「 + %b%d」`
    ls -l | grep 「picture」 | grep 「$time」 | awk ‘{print$NF}’ | xargs rm -rfgithub

  7.獲取不了網關mac地址
    問題：
    從2.14到3.65（映射地址2.141）網絡不通，可是從3端的其餘機器到3.65網絡OK。
    緣由：
    #arp
    Address HW type HW address Flags Mask Iface
    192.168.3.254 etherincompletCMbond0
    表面現象是機器自動獲取不了網關MAC地址，網絡工程師說是網絡設備的問題，具體不清。
    解決：
    arp綁定，arp -ibond0 -s 192.168.3.25400:00:5e:00:01:64正則表達式

   8.http服務沒法啓動一例
    問題：某天研發同事說網站前端環境http沒法啓動，我上去看了下。報以下錯：
    /etc/init.d/httpd start
    Starting httpd : [SatJan2917:49:002011] [warn] module antibot_moduleis already loaded,skipping
    Useproxy forwardas remoteip:true.
    Antibot exclude pattern:.*.[(js|css|jpg|gif|png)]
    Antibotseedcheckpattern:login
    (98)Address alreadyinuse : make_sock : could not bindto address [::] : 7080
    (98)Address alreadyinuse : make_sock : could not bindto address 0.0.0.0 : 7080
    nolistening socket savailable,shutting down
    Unableto openlog [FAILED]
    緣由：
    1）端口被佔用：表面看是7080端口被佔用，因而netstat-npl|grep7080看了下發現7080沒有佔用；
    2）在配置文件中重複寫了端口，若是在如下兩個文件同時寫了Listen7080
    /etc/httpd/conf/http.conf
    /etc/httpd/conf.d/t.10086.cn.conf
    解決：
    註釋掉/etc/httpd/conf.d/t.10086.cn.conf的Listen7080，重啓，OK。sql

9.too many openfile
    問題：
    報too many openfile錯誤
    解決：
    終極解決方案
    echo「」>>/etc/security/limits.conf
    echo「*softnproc65535″>>/etc/security/limits.conf
    echo「*hardnproc65535″>>/etc/security/limits.conf
    echo「*softnofile65535″>>/etc/security/limits.conf
    echo「*hardnofile65535″>>/etc/security/limits.conf
    echo「」>>/root/.bash_profile
    echo「ulimit-n65535″>>/root/.bash_profile
    echo「ulimit-u65535″>>/root/.bash_profile
    最後重啓機器或者執行ulimit-u655345&&ulimit-n65535

10.ibdata1和mysql-bin致磁盤空間問題
    問題：
    2.51磁盤空間報警，經查發現ibdata1和mysql-bin日誌佔用空間太多（其中ibdata1超過120G，mysql-bin超過80G）
    緣由：
    ibdata1是存儲格式，在INNODB類型數據狀態下，ibdata1用來存儲文件的數據和索引，而庫名的文件夾裏的那些表文件只是結構而已。
    innodb存儲引擎有兩種表空間的管理方式，分別是：
    1）共享表空間（可拆分爲多個小的表空間文件），這個是咱們目前多數數據庫使用的方法；
    2）獨立表空間，每個表有一個獨立的表空間（磁盤文件）
    對於兩種管理方式，各有優劣，具體以下：
    ①共享表空間：
    優勢：能夠將表空間分紅多個文件存放到不一樣的磁盤上（表空間文件大小不受表大小的限制，一個表能夠分佈在不一樣步的文件上）
    缺點：全部數據和索引存放在一個文件中，則隨着數據的增長，將會有一個很大的文件，雖然能夠把一個大文件分紅多個小文件，可是多個表及索引在表空間中混合存儲，這樣若是對於一個表作了大量刪除操做後表空間中將有大量空隙。對於共享表空間管理的方式下，一旦表空間被分配，就不能再回縮了。當出現臨時建索引或是建立一個臨時表的操做表空間擴大後，就是刪除相關的表也沒辦法回縮那部分空間了。
    ②獨立表空間：在配置文件（my.cnf）中設置：innodb_file_per_table
    特色：每一個表都有自已獨立的表空間；每一個表的數據和索引都會存在自已的表空間中。
    優勢：表空間對應的磁盤空間能夠被收回（Droptable操做自動回收表空間，若是對於刪除大量數據後的表能夠經過:altertabletbl_nameengine=innodb;回縮不用的空間。
    缺點：若是單表增長過大，如超過100G，性能也會受到影響。在這種狀況下，若是使用共享表空間能夠把文件分開，但有一樣有一個問題，若是訪問的範圍過大一樣會訪問多個文件，同樣會比較慢。若是使用獨立表空間，能夠考慮使用分區表的方法，在必定程度上緩解問題。此外，當啓用獨立表空間模式時，須要合理調整innodb_open_files參數的設置。
    解決:
    1）ibdata1數據太大：只能經過dump，導出建庫的sql語句，再重建的方法。
    2）mysql-binLog太大：
    ①手動刪除：
    刪除某個日誌：mysql>PURGEMASTERLOGSTO‘mysql-bin.010′;
    刪除某天前的日誌：mysql>PURGEMASTERLOGSBEFORE’2010-12-2213:00:00′;
    ②在/etc/my.cnf裏設置只保存N天的bin-log日誌
    expire_logs_days=30//BinaryLog自動刪除的天數

十一、Linux系統配置DNS

如上網卡IP地址配置完畢，若是服務器需上外網，還需配置域名解析地址（Domain Name System，DNS），DNS主要用於將請求的域名轉換爲IP地址，DNS地址配置方法以下：

修改vi /etc/resolv.conf 文件，在文件中加入以下兩條:

nameserver 202.106.0.20

nameserver 8.8.8.8

如上分別表示主DNS於備DNS，DNS配置完畢後，無需重啓網絡服務,DNS是當即生效。

能夠ping -c 6 www.baidu.com 查看返回結果，若是有IP返回，則表示服務器DNS配置正確，如圖3-13所示：

圖3-13 ping命令返回值

十二、更改inux網卡名稱命名

CentOS7服務器，默認網卡名爲ifcfg-eno16777736，若是咱們想改爲ifcfg-eth0，使用以下步驟便可：

編輯/etc/sysconfig/grub文件，命令爲vi /etc/sysconfig/grub，在倒數第二行quiet後加入以下代碼，並如圖3-14所示：

net.ifnames=0 biosdevname=0

圖3-14 網卡配置ifnames設置

執行命令grub2-mkconfig -o /boot/grub2/grub.cfg，生成新的grub.cfg文件，如圖3-15所示：

grub2-mkconfig -o /boot/grub2/grub.cfg

圖3-15 生成新的grub.cnf文件

重命名網卡名稱，執行命令mv ifcfg-eno16777736 ifcfg-eth0，修改ifcfg-eth0文件中DEVICE= eno16777736爲DEVICE= eth0，如圖3-16所示：

6 重命名網卡名稱

重啓服務器，並驗證網卡名稱是否爲eth0，Reboot完後，如圖3-17所示：

圖3-17 驗證網卡設備名稱

2、故障排查彙總表

序號	故障點	分析與解決
1	Linux系統安裝初始狀態時，找不到硬盤，並沒有法進入下一步安裝	進入COMS設置，找到硬盤設置的相關選項，並設置爲兼容模式
2	Linux系統安裝時，在硬盤分區完成後，沒法繼續安裝	硬盤分區不符合安裝要求，你可能忘記建立根分區或swap交換分區了，這一點與Windows系統的安裝有區別
3	Linux系統安裝時，制定安裝中，軟件包的選擇感受困惑，安裝完成後發現不符合咱們的要求，有些組件沒有安裝，而不須要的組件卻裝上了	對Linux系統的瞭解還太少，反覆安裝屢次後，天然掌握自如
4	代理服務器的配置過程當中，發現有些過濾規劃未起做用	（1）先檢查對應的功能模塊是否加載成功（2）默認策略是否設置恰當（3）iptables命令語法是否有錯（4）過濾規劃順序可能不當，需調整
5	代理服務器和防火牆的配置完成後，啓動服務，能夠訪問Internet，但不能訪問DMZ區的服務	（1）關閉iptables服務，看是否能夠訪問，若是不能，檢查連通性，若能訪問，說明iptables規則有問題，集中檢查過濾規則的配置與順序
6	再次配置好iptables過濾規則後，重啓iptables服務後，發現原有的規則所有丟失	（1）修改/etc/sysconfig/iptables-config配置文件，將IPTABLES_SAVE_ON_RESTART=」no」改成yes（2）用iptables-save > /etc/sysconfig/iptables命令保存
7	在交換機上劃分VLAN後，不能訪問外網	VLAN的網關未設置或設置不正確
8	在配置DNS服務中，named服務沒法啓動	形成問題可能性：（1）/etc/named目錄下缺乏必要文件（2）/var/named目錄下缺乏必要文件（3）named帳戶權限問題。解決方法：缺乏的文件必須複製到位，啓動文件必須將權限設置爲named帳戶和組帳戶
9	在配置DNS服務中，沒法正確解析域名或IP地址	（1）檢查並修改/var/named下的正向解析區文件和反向解析區文件中的語法與記錄設置（2）檢查/etc/named.conf配置中的zone區域聲明編寫是否有誤（3）檢查是否安裝了bind-chroot軟件包，如安裝了，區域數據庫文件應在/var/named/chroot/var/named目錄中（4）檢查/etc/resolv.conf配置文件是否設定了正確的nameserver
10	dhcpd服務啓動時，提示「No subnet declaration for eth0(10.10.10.2)」	說明eth0的IP地址設置不對，不在dhcp服務的做用域範圍內，必須將eth0的IP設置爲做用域範圍內的IP地址
11	在配置DHCP服務時，配置了多個做用域，結果只有一個做用域的地址能夠分配，其餘不能分配成功	說明主機的網絡接口卡只有一個，若有3個做用域，需配置3個網卡接口eth0、eth1和eth2，分別對應3個做用域。這是使用超級做用域的一種配置方法
12	MySQL數據庫的安裝不能成功，老是提示軟件的依賴關係，形成所要安裝的軟件包不能順利安裝	說明所要安裝的軟件包須要其餘組件或共享庫的支持，MySQL的rpm包安裝方式自己就繁瑣一些，要求安裝的軟件包比較多，包之間的依賴關係很是明顯，根據提示找到須要的組件包並安裝，安裝時要注意軟件包順序
13	測試Web服務，訪問主站點時，無網頁出現，但已經鏈接上服務器	在httpd.conf主配置文件中的「DocumentRoot」選項的設置不當，如/var/www/html/，最後的「/」不能加
14	遠程客戶端沒法訪問samba共享目錄，共享目錄在本地測試成功	關閉iptables服務
15	Samba的smb服務已經啓動成功，訪問samba某個共享目錄時，提示錯誤信息「NT_STATUS_BAD_NETWORK_NAME」	說明共享目錄沒有建立或不存在
16	Samba的smb服務已經啓動成功，提示錯誤信息「NT_STATUS_ACCESS_DENIED」	提示訪問被拒絕，多是登陸的用戶名或密碼有誤，或是iptables啓動了，關閉防火牆
17	Samba的smb服務已經啓動成功，提示錯誤信息「NT_STATUS_LOGON_FAILURE」	不容許當前用戶訪問當前共享目錄，說明此共享目錄設置只容許特定用戶訪問
18	FTP服務配置了本地用戶上傳，但在上傳數據到對應目錄時，提示被拒絕	可能該用戶帳戶對上傳目錄沒有寫權限
19	配置容許本地帳戶登陸FTP後，root帳戶沒法登陸，並提示「500 OOPS：cannot change directory:/root」的錯誤信息，而其餘本地帳戶能夠登陸FTP	檢查是否啓用了SELinux安全系統，並禁止SELinux，能夠編輯/etc/selinux/config文件，將配置項SELINUX=enforcing改成disabled
20	使用郵件客戶端能夠發送郵件，但不能接收郵件	檢查pop3服務是否啓動
21	mount命令掛載NFS服務的共享目錄，好久也沒有響應，NFS服務是正常的	portmap服務沒有啓動，必須啓動該服務
22	本地測試mount掛載NFS共享成功，但在其餘客戶主機mount鏈接時不成功	關閉iptables服務，再測試

3、Linux 4.1內核熱補丁成功實踐

十一、問題現象

現象一：CPU監控非0即100%

該問題現象表如今Redis進程CPU監控的峯值時而100% 時而爲0，有的甚至是幾十分鐘都爲0，突發1秒100%後又變爲0，以下圖。

而從大量機器的統計規律看，這個現象在2.6.32 內核不存在，在4.1內核存在幾例。2.6.32是咱們較早期採用的版本，爲平臺的穩定發展作了有力支撐，4.1 能夠知足不少新技術需求，如新款CPU、新板卡、RDMA、NVMe和binlog2.0等。後臺無縫維護着兩個版本，併爲了能力提高和優化而逐步向4.1及更高版本過渡。

現象二：top顯示非0即300%

登陸到機器上執行top -b -d 1 –p <pid> | grep<pid> , 能夠看到進程的CPU利用率每隔幾分鐘到幾十分鐘出現一次300%，這意味着該進程3個線程佔用的3個CPU都跑滿了，跟監控程序呈現一樣的異常。

問題分析

上述異常程序使用的是一樣的數據源：/proc/pid/stat中進程運行佔用的用戶態時間utime和內核態時間stime。咱們抓取utime和stime更新狀況後，發現utime或者stime每隔幾分鐘或者幾十分鐘才更新，更新的步進值達到幾百到1000+，而正常進程看到的是每幾秒更新，步進值是幾十。

定位到異常點後，還要找出緣由。排除了監控邏輯、IO負載、調用瓶頸等可能後，確認是4.1內核的CPU時間統計有 bug。

cputime統計邏輯

檢查/proc/pid/stat中utime和stime被更新的代碼執行路徑，在cputime_adjust()發現了一處可疑的地方：

當utime+stime>=rtime的時候就直接跳出了，也就是不更新utime和stime了！這裏的rtime是runtime，表明進程運行佔用的全部CPU時長，正常應該等於或近似進程用戶態時間+內核態時間。但內核配置了CONFIG_VIRT_CPU_ACCOUNTING_GEN選項，這會讓utime和stime分別單調增加。而runtime是調度器裏統計到的進程真正運行總時長。

內核每次更新/proc/pid/stat的utime和stime的時候，都會跟rtime對比。若是utime+stime很長一段時間都大於rtime，那代碼直接get out了， /proc/pid/stat就不更新了。只有當rtime持續更新追上utime+stime後，才更新utime和stime。

解決辦法：

冷補丁和熱補丁

第一回合：冷補丁

出現問題的代碼位置已經找到，那就先去內核社區看看有沒有成熟補丁可用，看一下kernel/sched/cputime.c的 changelog，看到一個patch：確保stime+utime=rtime。再看描述：像top這樣的工具，會出現超過100%的利用率，以後又一段時間爲0，這不就是咱們遇到的問題嗎？真是踏破鐵鞋無覓處，得來全不費工夫！（patch連接：https://lore.kernel.org/patchwork/patch/609410/）

該補丁在4.3內核及之後版本才提交，卻並未提交到4.1穩定版分支，因而移植到4.1內核。打上該補丁後進行壓測，再沒出現cputime時而100%時而0%的現象，而是0-100%之間平滑波動的值。

至此，你可能以爲問題已經解決了。可是，問題才解決了一半。而每每「可是」後邊纔是重點。

第二回合：熱補丁

給內核代碼打上該冷補丁只能解決新增服務器的問題，但公司還有數萬存量服務器是沒法升級內核後重啓的。

若是沒有其它好選擇，那存量更新將被迫採用以下的妥協方案：監控程序修改統計方式進行規避，再也不使用utime和stime，而是經過runtime來統計進程的執行時間。

雖然該方案快速可行，但也有很大的缺點：

1. 不少業務部門都要修改統計程序，研發成本較高；

2. /proc/pid/stat的utime和stime是標準統計方式，一些第三方組件並不容易修改；

3. 並無根本解決utime和stime不許的問題，用戶、研發、運維使用ps、top命令時還會產生困惑，產生額外的溝通協調成本。

幸虧，咱們還能夠依靠UCloud已屢次成功應用的技術：熱補丁技術。

所謂熱補丁技術，是指在有缺陷的服務器內核或進程正在運行時，對已經加載到內存的程序二進制打上補丁，使得程序實時在線狀態下執行新的正確邏輯。能夠簡單理解爲像關二爺那樣不打麻藥在清醒狀態下刮骨療傷。固然，對內核刮骨療傷內核是不會痛的，但刮很差內核就會直接死給你看，沒有絲毫猶豫，很是乾脆利索又耿直。

熱補丁修復

而本次熱補丁修復存在兩個難點：

難點一：熱補丁製做

此次熱補丁在結構體新增了spinlock成員變量，那就涉及新成員的內存分配和釋放，在結構體實例被複制和釋放時，都要額外的對新成員作處理，稍有遺漏可能會形成內存泄漏進而致使宕機，這就加大了風險。

再一個就是，結構體實例是在進程啓動時初始化的，對於已經存在的實例如何塞進新的spinlock成員？所謂兵來將擋水來土掩，咱們想到能夠在原生補丁使用spinlock成員的代碼路徑上攔截，若是發現實例不含該成員，則進行分配、初始化、加鎖、釋放鎖。

要解決問題，既要攀登困難的山峯，又得控制潛在的風險。團隊編寫了腳本進行幾百萬次的加載、卸載熱補丁測試，並沒有內存泄漏，單機穩定運行，再下一城。

難點二：難以復現

另外一個難題是該問題難以復現，只有在現網生產環境纔有幾個case可驗證熱補丁，而又不能夠拿用戶的環境去冒險。針對這種狀況咱們已經有標準化處理流程去應對，那就是設計完善的灰度策略，這也是UCloud內部一直在強調的核心理念和能力。通過分析，這個問題能夠拆解爲驗證熱補丁穩定性和驗證熱補丁正確性。因而咱們採起了以下灰度策略：

1. 穩定性驗證：先拿幾臺機器測試正常，再拿公司內部500臺次級重要的機器打熱補丁，灰度運行幾天正常，從而驗證了穩定性，風險盡在掌控之中。

2. 正確性驗證：找到一臺出現問題的機器，同時打印utime+stime以及rtime，根據代碼的邏輯，當rtime小於utime+stime時會執行老邏輯，當rtime大於utime+stime時會執行新的熱補丁邏輯。以下圖所示，進入熱補丁的新邏輯後，utime+stime打印正常且與rtime保持了同步更新，從而驗證了熱補丁的正確性。

3. 全網變動：最後再分批在現網環境機器上打熱補丁，執行全網變動，問題獲得根本解決。

4、Linux 管理員10 個常見問題

一、卸載無響應的 DVD 驅動器

按下服務器（運行基於 Redmond 的操做系統）DVD 驅動器上的 Eject 按鈕時，它會當即彈出。在大多數企業 Linux 服務器中，若是在那個目錄中運行某個進程，彈出就不會發生。

下面介紹如何找到保持 DVD 驅動器的進程，並輕鬆彈出 DVD 驅動器：首先進行模擬。在 DVD 驅動器中放入磁盤，打開一個終端，裝載 DVD 驅動器：

# mount /media/cdrom

# cd /media/cdrom

# while [ 1 ]; do echo "All your drives are belong to us!"; sleep 30; done

如今打開第二個終端並試着彈出 DVD 驅動器：

# eject

將獲得如下消息：

umount: /media/cdrom: device is busy

在釋放該設備以前，讓咱們找出誰在使用它

# fuser /media/cdrom

進程正在運行，沒法彈出磁盤實際上是咱們的錯誤。如今，若是您是根用戶，能夠隨意終止進程：

# fuser -k /media/cdrom

如今終於能夠卸載驅動器了：

# eject

fuser 很正常。

二、恢復出現問題的屏幕

如下操做：

# cat /bin/cat

注意！終端就想垃圾同樣。輸入的全部內容很是零亂。那麼該怎麼作呢？

輸入 reset。可是，輸入 reset 與輸入 reboot 或 shutdown 太接近了。

在進行此操做時，機器不會重啓。繼續操做：

# reset

如今屏幕恢復正常了。這比關閉窗口後再次登錄好多了，特別是必須通過 5 臺機器和 SSH 才能到達這臺機器時。

三、屏幕協做

來自產品工程的高級維護用戶 David 打電話說：「爲何我不能在您部署的這些新機器上編譯 supercode.c」。

運行的是Posh機器

（這個虛夠的公司將它的 5 臺生產服務器以記念 Spice Girls 的方式命名）。這下您能夠大顯身手了，另外一臺機器由 David 操做：

# su - david

轉到 posh：

# ssh posh

到達以後，運行如下代碼：

# screen -S foo

而後呼叫 David：「David，在終端運行命令 # screen -x foo」。

問題緣由：David 的編譯腳本對一個不在此新服務器上的舊目錄進行了硬編碼。將它裝載後再次編譯便可解決問題

注意：雙方須要以同一用戶登陸。screen 命令還能夠：實現多個窗口和拆分屏幕。

方法：Ctrl-A D

（即按住 Ctrl 鍵並點擊 A 鍵。而後按 D 鍵）。而後經過再次運行 screen -x foo 命令能夠從新拼接起來。

四、找回根密碼

若是忘記根密碼，就必須從新安裝整臺機器。

首先重啓系統。重啓時會跳出如圖 1 所示的 GRUB 屏幕。移動箭頭鍵，這樣能夠保留在此屏幕上，而不是進入正常啓動。

而後，使用箭頭鍵選擇要啓動的內核，並輸入 E 編輯內核行。而後即可看到如圖 2 所示的屏幕：

圖 2：準備編輯內核行

再次使用箭頭鍵突出顯示以 kernel 開始的行，按 E 編輯內核參數。到達如圖 3 所示的屏幕時，在圖 3 中所示的參數後追加數字 1 便可：

而後按 Enter 和 B，內核會啓動到單用戶模式。而後運行 passwd 命令，更改用戶根密碼：

sh-3.00# passwd

New UNIX password:

Retype new UNIX password:

passwd: all authentication tokens updated successfully

如今能夠重啓了，機器將使用新密碼啓動。

五、SSH 後門

我所在的站點須要某人的遠程支持，而他卻被公司防火強阻擋在外。不多有人意識到，若是能經過防火牆到達外部，那麼也能輕鬆實現讓外部的信息進來。從本意講，這稱爲「在防火牆上砸一個洞」。我稱之爲 SSH 後門。爲了使用它，必須有一臺做爲中介的鏈接到 Internet 的機器。在本例中，將這樣臺機器稱爲 blackbox.example.com。公司防火牆後面的機器稱爲 ginger。此技術支持的機器稱爲 tech。圖 4 解釋了設置過程。

操做步驟：

檢查什麼是容許作的，但要確保您問對了人。大多數人都擔憂您打開了防火牆，但他們不明白這是徹底加密的。並且，必須破解外部機器才能進入公司內部。不過，您可能屬於「敢做敢爲」型的人物。本身進行判斷應該選擇的方式，但不如意時不抱怨別人。

使用 -R 標記經過 SSH 從 ginger 鏈接到 blackbox.example.com。假設您是 ginger 上的根用戶，tech 須要根用戶 ID 來幫助使用系統。使用 -R 標記將 blackbox 上端口 2222 的說明轉發到 ginger 的端口 22 上。這就設置了 SSH 通道。注意，只有 SSH 通訊能夠進入 ginger：您不會將 ginger 放在無保護的 Internet 上。可使用如下語法實現此操做：

~# ssh -R 2222:localhost:22 thedude@blackbox.example.com

進入 blackbox 後，只需一直保持登陸狀態。我老是輸入如下命令：

thedude@blackbox:~$ while [ 1 ]; do date; sleep 300; done

使機器保持忙碌狀態。而後最小化窗口。

如今指示 tech 上的朋友使用 SSH 鏈接到 blackbox，而不須要使用任何特殊的 SSH 標記。但必須把密碼給他們：

root@tech:~# ssh thedude@blackbox.example.com

tech 位於 blackbox 上後，可使用如下命令從 SSH 鏈接到 ginger：

thedude@blackbox:~$: ssh -p 2222 root@localhost

Tech 將提示輸入密碼。應該輸入 ginger 的根密碼。如今您和來自 tech 的支持能夠一塊兒工做並解決問題。甚至須要一塊兒使用屏幕！

六、經過 SSH 通道進行遠程 VNC 會話

一般，當遠程服務器上的某類圖形程序只能在此服務器上使用時，才須要 VNC。

假設在技巧 5 中，ginger 是一臺存儲服務器。許多設備都使用 GUI 程序來管理存儲控制器。這些 GUI 管理工具一般須要經過一個網絡直接鏈接到存儲服務器，而這個網絡有時保存在專用的子網絡中。所以，只能經過 ginger 訪問這個 GUI。

能夠嘗試使用 -X 選項經過 SSH 鏈接到 ginger 並啓動它，但這對帶寬要求很高，您須要忍受等待的痛苦。VNC 是一個網絡友好的工具，幾乎適用於全部操做系統。

假設設置與技巧 5 中的同樣，但但願 tech 能訪問 VNC 而不是 SSH。對於這種狀況，須要進行一些相似的操做，不過轉發的是 VNC 端口。執行如下操做步驟：

在 ginger 上啓動一個 VNC 服務器會話。運行如下命令：

root@ginger:~# vncserver -geometry 1024x768 -depth 24 :99

這些選項指示啓動服務器，分辨率爲 1024×768，像素深度爲每像素 24 位。若是使用較慢的鏈接設置，8 也許是更好的選項。使用 :99 指定可訪問 VNC 服務器的端口。VNC 協議在 5900 處啓動，所以 :99 表示服務器可從端口 5999 訪問。

啓動該會話時，要求您指定密碼。用戶 ID 與啓動 VNC 服務器時的用戶相同（本例中就是根用戶）。

從 ginger 鏈接到 blackbox.example.com 的 SSH 將 blackbox 上的端口 5999 轉發到 ginger。這經過運行如下命令在 ginger 中完成：

root@ginger:~# ssh -R 5999:localhost:5999 thedude@blackbox.example.com

運行此命令後，須要將此 SSH 會話保持爲打開狀態，以便保留轉發到 ginger 的端口。此時，若是在 blackbox 上，那麼運行如下命令便可訪問 ginger 上的 VNC 會話：

thedude@blackbox:~$ vncviewer localhost:99

這將經過 SSH 將端口轉發給 ginger，但咱們但願經過 tech 讓 VNC 訪問 ginger。爲此，須要另外一個通道。在 tech 中，打開一個通道，經過 SHH 將端口 5999 轉發到 blackbox 上的端口 5999。這經過運行如下命令完成：

root@tech:~# ssh -L 5999:localhost:5999 thedude@blackbox.example.com

此次使用的 SSH 標記爲 -L，它不是將 5999 放到 blackbox，而是從中獲取。到達 blackbox 後，須要保持此會話爲打開狀態。如今便可在 tech 中使用 VNC 了！

在 tech 中，運行如下命令使 VNC 鏈接到 ginger：

root@tech:~# vncviewer localhost:99

Tech 如今將擁有一個直接到 ginger 的 VNC 會話。設置雖然有點麻煩，但比爲修復存儲陣列而四處奔波強多了。不過多實踐幾回這就變得容易了。

對此技巧我還要補充一點：若是 tech 運行的是 Windows® 操做系統，而且沒有命令行 SSH 客戶端，那麼 tech 能夠運行 Putty。Putty 能夠設置爲經過查找側欄中的選項來轉發 SSH 端口。若是端口是 5902 而不是本例中的 5999，則能夠輸入圖 5 中的內容。

若是進行了此設置，那麼 tech 就可使用 VNC 鏈接到 localhost:2，如同 tech 正在 Linux 操做系統上運行同樣。

七、檢查帶寬

設想：公司 A 有一個名爲 ginger 的存儲服務器，並經過名爲 beckham 的客戶端節點裝載 NFS。公司 A 肯定他們須要從 ginger 獲得更多的帶寬，由於有大量的節點須要 NFS 裝載 ginger 的共享文件系統。

實現此操做的最經常使用和最便宜的方式是將兩個吉比特以太網 NIC 組合在一塊兒。這是最便宜的，由於您一般會有一個額外的可用 NIC 和一個額外的端口。

因此採起此這個方法。不過如今的問題是：到底須要多少帶寬？

吉比特以太網理論上的限制是 128MBit/s。這個數字從何而來？看看這些計算：

1Gb = 1024Mb；1024Mb/8 = 128MB；」b」 = 「bits,」、」B」 = 「bytes」

但實際看到的是什麼呢，有什麼好的測量方法呢？我推薦一個工具 iperf。能夠按照如下方法得到 iperf：

# wget http://dast.nlanr.net/Projects/Iperf2.0/iperf-2.0.2.tar.gz

須要在 ginger 和 beckham 都可見的共享文件系統上安裝此工具，或者在兩個節點上編譯並安裝。我將在兩個節點都可見的 bob 用戶的主目錄中編譯它：

tar zxvf iperf*gz

cd iperf-2.0.2

./configure -prefix=/home/bob/perf

make

make install

在 ginger 上，運行：

# /home/bob/perf/bin/iperf -s -f M

這臺機器將用做服務器並以 MBit/s 爲單位輸出執行速度。

在 beckham 節點上，運行：

# /home/bob/perf/bin/iperf -c ginger -P 4 -f M -w 256k -t 60

兩個屏幕上的結果都指示了速度是多少。在使用吉比特適配器的普通服務器上，可能會看到速度約爲 112MBit/s。這是 TCP 堆棧和物理電纜中的經常使用帶寬。經過以端到端的方式鏈接兩臺服務器，每臺服務器使用兩個聯結的以太網卡，我得到了約 220MBit/s 的帶寬。

事實上，在聯結的網絡上看到的 NFS 約爲 150-160MBit/s。這仍然表示帶寬能夠達到預期效果。若是看到更小的值，則應該檢查是否有問題。

我最近碰到一種狀況，即經過鏈接驅動程序鏈接兩個使用了不一樣驅動程序的 NIC。這致使性能很是低，帶寬約爲 20MBit/s，比不鏈接以太網卡時的帶寬還小！

八、命令行腳本和實用程序

Linux 系統管理員經過使用權威的命令行腳本會變得更高效。這包括巧妙使用循環和知道如何使用 awk、grep 和 sed 等的實用程序解析數據。一般這能夠減小擊鍵次數，下降用戶出錯率。

例如，假設須要爲即將安裝的 Linux 集羣生成一個新的 /etc/hosts 文件。通常的作法是在 vi 或文本編輯器中添加 IP 地址。不過，能夠經過使用現有 /etc/hosts 文件並將如下內容追加到此文件來實現。在命令行上運行：

# P=1; for i in $(seq -w 200); do echo "192.168.99.$P n$i"; P=$(expr $P + 1);

done >>/etc/hosts

200 個主機名（n001 到 n200）將由 IP 地址（192.168.99.1 到 192.168.99.200）來建立。手動填充這樣的文件有可能會建立重複的 IP 地址或主機名，所以這是使用內置命令行消除用戶錯誤的好例子。請注意，這是在 bash shell（大多數 Linux 發行版的默認值）內完成的。

再舉一個例子，假設要檢查 Linux 集羣中的各個計算節點中的內存大小是否同樣。一般，擁有一個發行版或相似的 shell 是最好的。可是爲了演示，如下使用 SSH。假設 SSH 設置爲不使用密碼驗證。而後運行：

# for num in $(seq -w 200); do ssh n$num free -tm | grep Mem | awk '{print $2}';

done | sort | uniq

這樣的命令行至關簡潔。（若是在其中放入正則表達式狀況會更糟）。讓咱們對它進行細分，詳細討論各部分。

首先從 001 循環到 200。使用 seq 命令的 -w 選項在前面填充 0。而後替換 num 變量，建立經過 SSH 鏈接的主機。有了目標主機後，向它發出命令。本例中是：

free -m | grep Mem | awk '{print $2}'

一、這個命令的意思是：使用 free 命令獲取以兆字節爲單位的內存大小。

二、獲取這個命令的結果，並使用 grep 獲取包含字符串 Mem 的行。

三、獲取那一行並使用 awk 輸出第二個字段，它是節點中的總內存，在每一個節點上執行這個操做。

在每一個節點上執行命令後，200 個節點的整個輸出就傳送（|d）到 sort 命令，以對全部內存值進行排序。最後，使用 uniq 命令消除重複項。這個命令會致使如下狀況中的一種：

一、若是全部節點（n001 到 n200）擁有相同的內存大小，則只顯示一個數字。這個數字就是每一個操做系統看到的內存大小。

二、若是節點內存大小不一樣，將會看到幾個內存大小的值。

三、最後，若是某個節點上的 SSH 出現故障，則會看到一些錯誤消息。

這個命令並非天衣無縫的。若是發現與預期不一樣的內存值，您就不知道是哪個節點出了問題，或者有多少個節點。爲此須要發出另外一個命令。

這個技巧提供了一種查看某些內容的快速方式，並且若是發生錯誤，您能夠馬上知道。其價值在於快速檢查。

九、控制檯偵察

有些軟件會向控制檯輸出錯誤消息，而控制檯不必定會顯示在 SHH 會話中。使用 vcs 設備能夠進行檢查。在 SSH 會話中，在遠程服務器 # cat /dev/vcs1 上運行如下命令。這將顯示第一個控制檯中的內容。也可使用二、3 等查看其餘虛擬終端。若是某個用戶在遠程系統上輸入，您將看到他輸入的內容。

在大多數數據場中，使用遠程終端服務器、KVM 甚至 Serial Over LAN 是查看這類信息的最好方式；它也提供了帶外查看功能的一些好處。使用 vcs 設備可以提供一種快速帶內方法，這能節省去機房查看控制檯的時間。

十、隨機系統信息收集

在技巧 8 中，介紹了一個使用命令行獲取有關係統中總內存信息的例子。在這個技巧中，我將介紹幾個其餘方法，用於從須要進行驗證、故障診斷或給予遠程支持的系統收集重要信息。

首先，收集關於處理器的信息。經過如下命令很容易實現：

# cat /proc/cpuinfo

這個命令給出關於處理器的速度、數量和型號的信息。在許多狀況下使用 grep 能夠獲得須要的值。我常常作的檢查是肯定系統中處理器的數量。所以，若是我買了一臺帶雙核處理器的四核服務器，我能夠運行如下命令：

# cat /proc/cpuinfo | grep processor | wc -l

而後我看到值應該是 8。若是不是，我會打電話給供應商，讓他們給我派送另外一臺處理器。

我須要的另外一條信息是磁盤信息。可使用 df 命令得到。我老是添加 -h 標記，以便看到以十億字節或兆字節爲單位的輸出。# df -h 還會顯示磁盤的分區狀況。

列表最後是查看系統固件的方式 —— 一個獲取 BIOS 級別和 NIC 上的固件信息的方法。

要檢查 BIOS 版本，能夠運行 dmidecode 命令。遺憾的是，不能輕易使用 grep 獲取信息，因此這不是一個頗有效的方法。對於個人 Lenovo T61 laptop，輸出以下：

#dmidecode | less