기술 · 실용 가이드
Linux에서 “inotify watch limit reached”가 뜰 때: sysctl을 늘리기 전에 프로세스와 한도를 증명하세요
inotify의 ENOSPC는 사용자별 인스턴스 고갈, watch 고갈 또는 별개의 이벤트 큐 오버플로를 뜻할 수 있습니다. 먼저 활성 디스크립터와 감시 객체를 실제 소유 프로세스에 연결한 뒤 범위를 줄이거나 증명된 경계만 높입니다.
inotify의 ENOSPC는 사용자별 인스턴스 고갈, watch 고갈 또는 별개의 이벤트 큐 오버플로를 뜻할 수 있습니다. 먼저 활성 디스크립터와 감시 객체를 실제 소유 프로세스에 연결한 뒤 범위를 줄이거나 증명된 경계만 높입니다.
max_user_instances와 max_user_watches는 실제 사용자 ID별로 계산됩니다. max_queued_events는 새 inotify 인스턴스에 대기할 수 있는 이벤트 수를 제한합니다.
1. 호출자와 계산되는 ID를 보존하세요
재시작 전에 전체 ENOSPC 메시지, 프로그램, PID, 유효 UID와 실제 UID, 컨테이너 또는 서비스 경계, 감시 루트, 최초 시각을 기록합니다. 커널 객체를 가진 호스트에서 세 fs.inotify 현재값도 저장합니다.
errno 이름만 보고 디스크 부족으로 단정하거나 인터넷의 고정 sysctl 값을 바로 적용하지 마세요. 세 설정은 다른 자원을 제어하며 같은 실제 UID의 여러 프로세스가 사용자별 풀을 공유합니다.
2. 인스턴스·watch·큐 경계를 분리하세요
inotify 인스턴스를 만들 때 실패하면 인스턴스 상한을, watch를 추가할 때 실패하면 watch 상한을 의심합니다. 라이브러리가 실제 시스템 호출을 감출 수 있으므로 원래 호출 경로를 보존합니다.
큐 오버플로는 별개입니다. 인스턴스는 이미 존재하고 소비가 늦어 커널이 IN_Q_OVERFLOW를 보냅니다. max_user_watches를 늘려도 이미 유실된 이벤트는 복구되지 않아 재검색이 필요합니다.
3. fdinfo로 실제 소유권을 찾으세요
PID와 실제 UID별로 inotify 파일 디스크립터를 열거하고 /proc/<pid>/fdinfo/<fd>를 확인합니다. inotify 행으로 watch 수를 추정하고 공개 티켓에는 wd, inode, device, mask의 작은 표본만 남깁니다.
가장 큰 소비 프로세스와 의도한 감시 루트를 비교합니다. 재귀 도구는 많은 watch가 정당할 수 있지만 중복 의존성 트리, 생성 출력, 바인드 마운트, 재시작 루프는 수를 크게 늘립니다.
4. 롤백과 함께 가장 좁은 원인을 고치세요
중복 루트를 제거하고 지원되는 도구에서는 생성물과 의존성 디렉터리를 제외하며 인스턴스를 누수하는 초기화 루프를 고칩니다. 증거를 보존한 뒤 식별한 프로세스만 재시작합니다.
측정된 정상 상태 수요가 증명된 한도를 넘을 때만 관리되는 sysctl 방식으로 그 항목 하나를 바꿉니다. 이전 값, 이유, 예상 최대치와 롤백 조건을 기록하고 세 항목을 함께 올리지 않습니다.
5. 재시작 후 watch와 이벤트 전달을 검증하세요
제어된 작업 하나를 시작해 실제 UID와 PID의 새 인스턴스 및 watch 수가 예상 범위에서 안정되고 다시 빌드할 때마다 증가하지 않는지 확인합니다.
감시 루트에서 대표 파일을 생성·수정·이름 변경·삭제하고 필요한 이벤트가 모두 도착하는지, IN_Q_OVERFLOW가 없는지, 다른 사용자에게 여유가 있는지 확인합니다. 실패하면 변경을 되돌립니다.
