ls 在小目錄中花費很長時間

ls 在小目錄中花費很長時間

運行 Ubuntu,我打開一個終端並執行以下操作

sudo bash
cd /
ls | head -n 1000

預計會回傳約 20 個目錄。

但是,如果我執行 ls,並且不將其通過管道傳輸到任何內容,則 ls 只會掛在那裡,直到我從另一個終端殺死它。可能會發生什麼事?

編輯:

> type ls
ls is aliased to `ls --color=auto`

編輯:

> /bin/ls /
<normal response>
> /bin/ls --color=auto
<hangs indefinitely>

為什麼對 ls 的輸出進行著色會導致該命令掛起?

答案1

如果您正常執行 ls,它只會顯示檔案列表,而無需對其中任何一個執行 stat(2)。換句話說,它不訪問文件本身,而僅訪問包含文件的目錄。

如果新增 --color 選項,或使用其他需要檢查檔案本身的 ls 選項,則 ls 將需要 stat(2) 這些檔案。

最有可能的是,您目錄中的至少一個檔案實際上是透過 NFS 或類似方式從遠端系統掛載的。並且您安裝該分割區的伺服器未啟動或沒有回應。因此,當 ls 嘗試獲取有關該目錄的資訊時,它將掛在核心中等待伺服器回應。

正如其他人所提到的,如果您使用 strace,您會發現 ls 掛起時試圖存取哪個目錄。然後您可以卸載已安裝的分割區或其他任何東西。

相關內容