使用lsof處理文件恢復、句柄以及空間釋放問題

原文轉自:https://segmentfault.com/a/1190000000461077

曾經在生產上遇到過一個df 和 du出現的結果不一致的問題，爲了排查到底是哪個進程佔用了文件句柄，導致空間未釋放，首先在linux上面，一切皆文件，這個問題可以使用lsof這個BT的命令來處理（這個哈還可以來查詢文件句柄泄露問題，應用程序的進程未關閉文件句柄）

1.文件句柄以及空間釋放問題

• 注：在生產環境常見的問題就是，有維護人員或者開發同事使用tail命令實時查看日誌。然後另外的人使用rm命令刪除，這有就好導致磁盤空間不會真正的釋放，因爲你要刪除的文件，還有進程在使用，文件句柄沒有釋放，即tail

模擬場景1：

你創建一個文件testfile

touch testfile

然後使用tail命令一直查看

tail testfile

這個時候另外一個同事使用rm命令來刪除了該文件

rm testfile

正式使用lsof命令排查

如果你知道文件名，那就可以直接使用如下命令

lsof |grep  testfile

但是如果你不知道是哪個文件，或者是很多文件都有這樣的情況，那你需要使用如下命令

lsof |grep deleted 注：這個deleted表示該已經刪除了的文件，但是文件句柄未釋放,這個命令會把所有的未釋放文件句柄的進程列出來

注：有些系統你沒有配置環境變量的話，直接lsof是會報錯沒有該命令，你可以直接/usr/bin/lsof 或者是/usr/sbin/lsof，根據你的系統環境自己查看

然後上面命令出來的結果會出來如下結果

root 123 12244 0 14:47 pts/1 01:02:03  tail testfile

然後你可以使用kill 命令來釋放文件句柄從而釋放空間

kill 123

2. 文件恢復問題

在說明問題之前，先介紹下一些文件的基本概念：

• 文件實際上是一個指向inode的鏈接, inode鏈接包含了文件的所有屬性, 比如權限和所有者, 數據塊地址(文件存儲在磁盤的這些數據塊中). 當你刪除(rm)一個文件, 實際刪除了指向inode的鏈接, 並沒有刪除inode的內容. 進程可能還在使用. 只有當inode的所有鏈接完全移去, 然後這些數據塊將可以寫入新的數據.

• proc文件系統可以協助我們恢復數據. 每一個系統上的進程在/proc都有一個目錄和自己的名字， 裏面包含了一個fd(文件描述符)子目錄(進程需要打開文件的所有鏈接). 如果從文件系統中刪除一個文件, 此處還有一個inode的引用:

/proc/進程號/fd/文件描述符

• 你需要知道打開文件的進程號(pid)和文件描述符(fd). 這些都可以通過lsof工具方便獲得, lsof的意思是”list open files, 列出(進程)打開的文件”. 然後你將可以從/proc拷貝出需要恢復的數據.

1.創建一個測試文件並且備份下，方面後續驗證

touch testfile
cp testfile testfile.backup.2014

2.查看文件的相關信息

stat testfile

File: 'testfile'Size: 343545 Blocks: 241 IO Block: 4096 regular file
Device: fd00h/64768d Inode: 361579 Links: 1Access: (0664/-rw-rw-r–) Uid: ( 505/ zhaoke) Gid: ( 505/ zhaoke)
Access: 2014-11-09 15:00:38.000000000 +0800Modify: 2014-11-09 15:00:34.000000000 +0800Change: 2014-04-09 15:00:34.000000000 +0800

沒問題, 繼續下面工作:

3.刪除文件

rm testfile

4.查看文件

ls -l testfilels: testfile: No such file or directory

stat testfilestat: cannot stat 'testfile': No such file or directory

testfile文件刪除了，但不要終止仍在使用文件的進程， 因爲一旦終止, 文件將很難恢復.

現在我們開始找回數據之旅，先使用lsof命令查看下

lsof | grep testfile
tail 5317 root 4r REG 253,0 343545  361579  /root/testfile (deleted)

• 第一個縱行是進程的名稱(命令名), 第二縱行是進程號(PID), 第四縱行是文件描述符

• 現在你知道5317進程仍有打開文件, 文件描述符是4. 那我們開始從/proc裏面拷貝出數據.

• 你可能會考慮使用cp -a, 但實際上沒有作用, 你將拷貝的是一個指向被刪除文件的符號鏈接:

ls -l /proc/5317/fd/4lr-x—— 1 root root 64  09 15:00 /proc/5317/fd/4 -> /root/testfile (deleted)

使用cp -a命令測試恢復

 cp -a /proc/5317/fd/4 testfile.backup

使用ls命令來查看

ls -l testfile.backup
lrwxrwxrwx 1 root root 29  09 15:02 testfile.backup -> /roor/testfile (deleted)

通過上面的命令我們發現，使用cp -a命令，其恢復的是一個指向被刪除文件的符號鏈接

使用file命令分別查看文件和文件描述符

• 1.查看文件

file testfile.backup
testfile.backup: broken symbolic link to '/root/testfile (deleted)'

• 2.查看文件描述符

file /proc/5317/fd/4/proc/5317/fd/4: broken symbolic link to '/root/myfile (deleted)'

根據上面的file結果，可以使用cp拷貝出文件描述符數據到一個文件中，如下:

cp /proc/5317/fd/4 testfile.new

使用上面的命令恢復後，我們需要最終確認一下文件是否恢復，以及文件內容是否正確:

 ls -l testfile.new

然後把新舊的兩個文件對比

diff testfile.new myfile.backup




lsof使用實例
 
SECTION "lsof使用實例" [6313-6341]
一、查找誰在使用文件系統
在卸載文件系統時，如果該文件系統中有任何打開的文件，操作通常將會失敗。那麼通過lsof可以找出那些進程在使用當前要卸載的文件系統，如下： 
# lsof  /GTES11/
COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME
bash    4208 root  cwd    DIR    3,1 4096    2 /GTES11/
vim     4230 root  cwd    DIR    3,1 4096    2 /GTES11/
在這個示例中，用戶root正在其/GTES11目錄中進行一些操作。一個 bash是實例正在運行，並且它當前的目錄爲/GTES11，另一個則顯示的是vim正在編輯/GTES11下的文件。要成功地卸載/GTES11，應該在通知用戶以確保情況正常之後，中止這些進程。 這個示例說明了應用程序的當前工作目錄非常重要，因爲它仍保持着文件資源，並且可以防止文件系統被卸載。這就是爲什麼大部分守護進程（後臺進程）將它們的目錄更改爲根目錄、或服務特定的目錄（如 sendmail 示例中的 /var/spool/mqueue）的原因，以避免該守護進程阻止卸載不相關的文件系統。 
SECTION "一、查找誰在使用文件系統" [6342-7488]
二、恢復刪除的文件
當Linux計算機受到***時，常見的情況是日誌文件被刪除，以掩蓋***者的蹤跡。管理錯誤也可能導致意外刪除重要的文件，比如在清理舊日誌時，意外地刪除了數據庫的活動事務日誌。有時可以通過lsof來恢復這些文件。 
當進程打開了某個文件時，只要該進程保持打開該文件，即使將其刪除，它依然存在於磁盤中。這意味着，進程並不知道文件已經被刪除，它仍然可以向打開該文件時提供給它的文件描述符進行讀取和寫入。除了該進程之外，這個文件是不可見的，因爲已經刪除了其相應的目錄索引節點。 
在/proc 目錄下，其中包含了反映內核和進程樹的各種文件。/proc目錄掛載的是在內存中所映射的一塊區域，所以這些文件和目錄並不存在於磁盤中，因此當我們對這些文件進行讀取和寫入時，實際上是在從內存中獲取相關信息。大多數與 lsof 相關的信息都存儲於以進程的 PID 命名的目錄中，即 /proc/1234 中包含的是 PID 爲 1234 的進程的信息。每個進程目錄中存在着各種文件，它們可以使得應用程序簡單地瞭解進程的內存空間、文件描述符列表、指向磁盤上的文件的符號鏈接和其他系統信息。lsof 程序使用該信息和其他關於內核內部狀態的信息來產生其輸出。所以lsof 可以顯示進程的文件描述符和相關的文件名等信息。也就是我們通過訪問進程的文件描述符可以找到該文件的相關信息。 
  
當系統中的某個文件被意外地刪除了，只要這個時候系統中還有進程正在訪問該文件，那麼我們就可以通過lsof從/proc目錄下恢復該文件的內容。 假如由於誤操作將/var/log/messages文件刪除掉了，那麼這時要將/var/log/messages文件恢復的方法如下： 
首先使用lsof來查看當前是否有進程打開/var/logmessages文件，如下： 
# lsof |grep /var/log/messages
syslogd   1283      root    2w      REG        3,3  5381017    1773647 /var/log/messages (deleted)
從上面的信息可以看到 PID 1283（syslogd）打開文件的文件描述符爲 2。同時還可以看到/var/log/messages已經標記被刪除了。因此我們可以在 /proc/1283/fd/2 （fd下的每個以數字命名的文件表示進程對應的文件描述符）中查看相應的信息，如下： 
# head -n 10 /proc/1283/fd/2
Aug  4 13:50:15 holmes86 syslogd 1.4.1: restart.
Aug  4 13:50:15 holmes86 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Aug  4 13:50:15 holmes86 kernel: Linux version 2.6.22.1-8 ([email protected]) (gcc version 4.2.0) #1 SMP Wed Jul 18 11:18:32 EDT 2007
Aug  4 13:50:15 holmes86 kernel: BIOS-provided physical RAM map:
Aug  4 13:50:15 holmes86 kernel:  BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
Aug  4 13:50:15 holmes86 kernel:  BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
Aug  4 13:50:15 holmes86 kernel:  BIOS-e820: 0000000000100000 - 000000001f7d3800 (usable)
Aug  4 13:50:15 holmes86 kernel:  BIOS-e820: 000000001f7d3800 - 0000000020000000 (reserved)
Aug  4 13:50:15 holmes86 kernel:  BIOS-e820: 00000000e0000000 - 00000000f0007000 (reserved)
Aug  4 13:50:15 holmes86 kernel:  BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
從上面的信息可以看出，查看 /proc/8663/fd/15 就可以得到所要恢復的數據。如果可以通過文件描述符查看相應的數據，那麼就可以使用 I/O 重定向將其複製到文件中，如: 
cat /proc/1283/fd/2 > /var/log/messages 
對於許多應用程序，尤其是日誌文件和數據庫，這種恢復刪除文件的方法非常有用。