科技 · 實用指南

Linux 顯示「inotify 監看數已達上限」？調高 sysctl 前先證明程序與限制

inotify 回傳 ENOSPC，可能是單一使用者的實例耗盡、監看項耗盡，也可能另有事件佇列溢位。先把活動描述元與監看物件歸屬到真實程序，再縮小範圍，或只提高已證實的邊界。

作者 Watch at Ease News · 3 分鐘閱讀發布於 2026年10月19日凌晨2:17 UTC

max_user_instances 與 max_user_watches 都依真實使用者 ID 計帳。 max_queued_events 限制新建 inotify 實例可排隊的事件數。

1. 凍結呼叫者與計帳身分

重新啟動前，記錄完整 ENOSPC 訊息、程式、PID、有效與真實 UID、容器或服務邊界、監看根目錄及首個時間戳，並讀取真正持有核心物件之主機上的三個 fs.inotify 目前值。

不要因 errno 名稱就假設是磁碟容量，也不要先貼上網路流傳的 sysctl 數值。三個控制項回答不同問題，同一真實 UID 之下的多個程序會共用配額。

建立 inotify 實例時失敗較接近實例上限；新增 watch 時失敗較接近監看上限，但函式庫可能隱藏實際系統呼叫，因此要保留原始呼叫路徑。

佇列溢位是另一類故障：實例已存在，消費者讀取速度不足，核心會送出 IN_Q_OVERFLOW。提高 max_user_watches 無法找回已遺失事件，應用程式必須重新掃描。

依 PID 與真實 UID 列出 inotify 檔案描述元，再查看 /proc/<pid>/fdinfo/<fd>。統計 inotify 列以估算每個描述元和程序的 watch 數，只保留少量 wd、inode、device 與 mask 樣本，避免公開敏感路徑樹。

將最大消耗程序與預期監看根比對。遞迴工具可能合理需要許多 watch，但重複相依樹、產生目錄、bind mount 或重啟迴圈會放大數量；容器還可能需要主機側 UID 映射。

先移除重複監看根，在工具支援時排除產生或相依目錄，並修正洩漏實例的重啟或初始化迴圈。保留證據後只重啟已辨識程序；整機重啟會抹去歸屬證據。

若量測證明合法穩態需求超出該上限，只透過系統管理的 sysctl 機制調整那一項。保存舊值、理由、預期峰值與回復觸發條件，不要同時提高三項。

啟動一個受控工作負載，記錄該真實 UID 與 PID 的新實例數與 watch 數，確認數量在預期範圍內穩定，不會每次建置或重連後持續上升。

在監看根內建立、修改、重新命名及刪除代表性檔案，確認應用收到所需事件、沒有 IN_Q_OVERFLOW，其他使用者仍有餘量；若未通過驗收就回復變更。