1、簡介
lsof(list open files)是一個列出當前系統打開文件的工具。在linux環境下，任何事物都以文件的形式存在，通過文件不僅僅可以訪問常規數據，還可以訪問網絡連接和硬件。所以如傳輸控制協議 (TCP) 和用戶數據報協議 (UDP) 套接字等，系統在后台都為該應用程序分配了一個文件描述符，無論這個文件的本質如何，該文件描述符為應用程序與基礎操作系統之間的交互提供了通用接口。因為應用程序打開文件的描述符列表提供了大量關於這個應用程序本身的信息，因此通過lsof工具能夠查看這個列表對系統監測以及排錯將是很有幫助的。
2、輸出信息含義
在終端下輸入lsof即可顯示系統打開的文件，因為 lsof 需要訪問核心內存和各種文件，所以必須以 root 用戶的身份運行它才能夠充分地發揮其功能。
直接輸入lsof部分輸出為:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME init 1 root cwd DIR 8,1 4096 2 / init 1 root rtd DIR 8,1 4096 2 / init 1 root txt REG 8,1 150584 654127 /sbin/init udevd 415 root 0u CHR 1,3 0t0 6254 /dev/null udevd 415 root 1u CHR 1,3 0t0 6254 /dev/null udevd 415 root 2u CHR 1,3 0t0 6254 /dev/null udevd 690 root mem REG 8,1 51736 302589 /lib/x86_64-linux-gnu/libnss_files-2.13.so syslogd 1246 syslog 2w REG 8,1 10187 245418 /var/log/auth.log syslogd 1246 syslog 3w REG 8,1 10118 245342 /var/log/syslog dd 1271 root 0r REG 0,3 0 4026532038 /proc/kmsg dd 1271 root 1w FIFO 0,15 0t0 409 /run/klogd/kmsg dd 1271 root 2u CHR 1,3 0t0 6254 /dev/null
每行顯示一個打開的文件，若不指定條件默認將顯示所有進程打開的所有文件。
lsof輸出各列信息的意義如下：
- COMMAND：進程的名稱 PID：進程標識符
- USER： 進程所有者
- FD： 文件描述符，應用程序通過文件描述符識別該文件。如cwd、txt等
- TYPE： 文件類型，如DIR、REG等
- DEVICE： 指定磁盤的名稱
- SIZE： 文件的大小
- NODE： 索引節點（文件在磁盤上的標識）
- NAME： 打開文件的確切名稱
FD 列中的文件描述符cwd 值表示應用程序的當前工作目錄，這是該應用程序啟動的目錄，除非它本身對這個目錄進行更改,txt 類型的文件是程序代碼，如應用程序二進制文件本身或共享庫，如上列表中顯示的 /sbin/init 程序。其次數值表示應用程序的文件描述符，這是打開該文件時返回的一個整數。如上的最后一行文件/dev/initctl，其文件描述符為 10。u 表示該文件被打開並處於讀取/寫入模式，而不是只讀 ® 或只寫 (w) 模式。同時還有大寫 的W 表示該應用程序具有對整個文件的寫鎖。該文件描述符用於確保每次只能打開一個應用程序實例。初始打開每個應用程序時，都具有三個文件描述符，從 0 到 2，分別表示標准輸入、輸出和錯誤流。所以大多數應用程序所打開的文件的 FD 都是從 3 開始。
Type 列則比較直觀，件和目錄分別稱為 REG 和 DIR。而CHR 和 BLK，分別表示字符和塊設備；或者 UNIX、FIFO 和 IPv4，分別表示 UNIX 域套接字、先進先出 (FIFO) 隊列和網際協議 (IP) 套接字。
3、常用參數
lsof語法格式是：
lsof ［options］ filename
lsof abc.txt 顯示開啟文件abc.txt的進程 lsof -c abc 顯示abc進程現在打開的文件 lsof -p 30297 //顯示哪些文件被pid為30297的進程打開 lsof -c -p 1234 列出進程號為1234的進程所打開的文件 lsof -g gid 顯示歸屬gid的進程情況 lsof +d /usr/local/ 顯示目錄下被進程開啟的文件 lsof +D /usr/local/ 同上，但是會搜索目錄下的目錄，時間較長 lsof -d 4 顯示使用fd為4的進程 lsof -u1000 //查看uid是100的用戶的進程的文件使用情況 lsof -utony //查看用戶tony的進程的文件使用情況 lsof -u^tony //查看不是用戶tony的進程的文件使用情況(^是取反的意思) lsof -i //顯示所有打開的端口 lsof -i:80 //顯示打開80端口的進程 lsof -i -U //顯示所有打開的端口和UNIX domain文件 lsof -i[46] [protocol][@hostname|hostaddr][:service|port] 46 --> IPv4 or IPv6 protocol --> TCP or UDP hostname --> Internet host name hostaddr --> IPv4地址 service --> /etc/service中的 service name (可以不止一個) port --> 端口號 (可以不止一個) lsof -i UDP@[url]www.akadia.com:123 //顯示哪些進程打開了到www.akadia.com的UDP的123(ntp)端口的鏈接 lsof -i tcp@ohaha.ks.edu.tw:ftp -r //不斷查看目前ftp連接的情況(-r，lsof會永遠不斷的執行，直到收到中斷信號,+r，lsof會一直執行，直到沒有檔案被顯示,缺省是15s刷新) lsof -i tcp@ohaha.ks.edu.tw:ftp -n //lsof -n 不將IP轉換為hostname，缺省是不加上-n參數
4、lsof使用實例
4.1、查找誰在使用文件系統
在卸載文件系統時，如果該文件系統中有任何打開的文件，操作通常將會失敗。那么通過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）的原因，以避免該守護進程阻止卸載不相關的文件系統。
4.2、恢復刪除的文件
當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 (root@everestbuilder.linux-ren.org) (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
對於許多應用程序，尤其是日志文件和數據庫，這種恢復刪除文件的方法非常有用。
4.3、實用命令
lsof `which httpd` //那個進程在使用apache的可執行文件 lsof /etc/passwd //那個進程在占用/etc/passwd lsof /dev/hda6 //那個進程在占用hda6 lsof /dev/cdrom //那個進程在占用光驅 lsof -c sendmail //查看sendmail進程的文件使用情況 lsof -c courier -u ^zahn //顯示出那些文件被以courier打頭的進程打開，但是並不屬於用戶zahn lsof -p 30297 //顯示那些文件被pid為30297的進程打開 lsof -D /tmp 顯示所有在/tmp文件夾中打開的instance和文件的進程。但是symbol文件並不在列 lsof -u1000 //查看uid是100的用戶的進程的文件使用情況 lsof -utony //查看用戶tony的進程的文件使用情況 lsof -u^tony //查看不是用戶tony的進程的文件使用情況(^是取反的意思) lsof -i //顯示所有打開的端口 lsof -i:80 //顯示所有打開80端口的進程 lsof -i -U //顯示所有打開的端口和UNIX domain文件 lsof -i UDP@[url]www.akadia.com:123 //顯示那些進程打開了到www.akadia.com的UDP的123(ntp)端口的鏈接 lsof -i tcp@ohaha.ks.edu.tw:ftp -r //不斷查看目前ftp連接的情況(-r，lsof會永遠不斷的執行，直到收到中斷信號,+r，lsof會一直執行，直到沒有檔案被顯示,缺省是15s刷新) lsof -i tcp@ohaha.ks.edu.tw:ftp -n //lsof -n 不將IP轉換為hostname，缺省是不加上-n參數
5、參考資料
http://www.cnblogs.com/ggjucheng/archive/2012/01/08/2316599.html