Пакетный unit руками не редактируют. Типовой постмортем: лимит дескрипторов подняли прямо в /usr/lib/systemd/system/proxy.service. Обновление заменило файл, рестарт вернул прежний лимит. Мониторинг показал таймауты upstream, дежурный пошёл искать сетевые потери. В журнале прокси — EMFILE. Ядро отказало процессу в новых дескрипторах; добавлять реплики вслепую — платный способ размножить дефект. Сначала устанавливаем факты: systemctl cat proxy.service покажет файлы конфигурации, systemctl show proxy.service -p LimitNOFILE -p LimitNOFILESoft — значения менеджера. Затем pid=$(systemctl show proxy.service -p MainPID --value); cat /proc/$pid/limits. При ненулевом PID считаем открытые FD: ls -U /proc/$pid/fd | wc -l. Сопоставляем число с soft limit. Общесистемный cat /proc/sys/fs/file-nr нужен для другого масштаба: свободный запас файловых дескрипторов системы не отменяет лимит конкретного процесса. Исправление доставляем из репозитория в /etc/systemd/system/proxy.service.d/limits.conf: секция Service, следующей строкой LimitNOFILE=65536:65536. Число выбираем по нагрузке и возможностям демона. Выполняем systemctl daemon-reload, затем плановый systemctl restart proxy.service и проверяем /proc у нового PID. Перечитывание unit само по себе лимит работающего процесса не меняет. Правила применения drop-in: systemd.unit. Drop-in тоже можно превратить в ручной мусор. Неизменяемость обеспечивают доставка из версионируемого источника, контроль дрейфа и проверка пересоздания узла. Копия всего vendor unit в /etc дополнительно замораживает его старые настройки. Для одного лимита достаточно одного управляемого переопределения; Kubernetes ради этого не требуется. https://ftops.space/?utm*source=telegram&utm*medium=smm&utm*campaign=ftops&utm*content=systemd-drop-in-overrides-vs-ruchnye