Найти и устранить утечку файловых дескрипторов

В контейнере крутится сервис leaky-service (Python). Каждый запрос он
открывает /etc/hostname для логирования, но не закрывает FD. Со временем
число открытых дескрипторов растёт и в проде оно упрётся в ulimit -n
(Too many open files).

Задача

Довести количество открытых FD процессом leaky-service до значения
≤ FD_BUDGET (по умолчанию 100). Возможные пути:

1. Перезапустить сервис (FD освободятся) — но это не починка, а скрытие.
   В этой лабе принимается, если после перезапуска счётчик действительно
   держится ниже бюджета.
2. Найти и устранить причину утечки в коде сервиса — правильное решение,
   но требует больше работы.

В проверочном стенде сервис после up уже проработал некоторое время и
накопил утечку. Минимальный успех = после вашего вмешательства в
/proc/<pid>/fd не больше FD_BUDGET записей.

Симптомы

$ ls /proc/$(pgrep -f leaky-service)/fd | wc -l
327

$ ls -l /proc/$(pgrep -f leaky-service)/fd | awk '{print $11}' | sort | uniq -c | sort -rn | head
    327 /etc/hostname     ← вот ваша утечка
      ...

327 открытых FD на /etc/hostname — однозначный сигнал. Один файл открыт
сотнями дескрипторов одновременно.

Почему это hard

Утечки FD — коварный production-баг: на тестах всё работает (FD копится
медленно), а в проде через сутки падает с EMFILE. Найти утечку — значит
сопоставить «открыл N раз» и «закрыл N раз» в коде, либо пройтись по
/proc/<pid>/fd и увидеть, какой файл утекает. Решение — либо фикс в коде
(with open(...)), либо prlimit/systemd LimitNOFILE (но это маскирует,
не лечит).