Симптом
Выполнили «restart» сервиса через панель или оркестратор — а эффекта нет: новый порт не слушается, зависшие ресурсы не освободились, изменение конфига не подхватилось. Команда при этом отработала без ошибок.
Причина
Многие «restart» на деле — hot-reload: процессу шлётся сигнал перечитать конфиг, но сам процесс не пересоздаётся, PID остаётся прежним. Последствия:
- новый инбаунд или порт начинает слушаться только после полного пересоздания контейнера, а не после мягкого reload;
- утёкшие ресурсы — файловые дескрипторы, память, зависшие сессии — при reload не освобождаются: их держит тот же живой процесс;
- часть изменений конфигурации reload просто игнорирует.
Решение
Отличайте hot-reload от полного рестарта явно. Факт пересоздания процесса проверяется по времени старта:
ps -o pid,lstart,cmd -C <процесс>
Если PID и lstart прежние — процесс не перезапускался, что бы ни ответила панель.
Когда нужен именно полный перезапуск — новый слушающий порт, сброс утечки, глубокая смена конфигурации — делайте docker restart <контейнер>, а не мягкий reload оркестратора. Для конфигурационных файлов, смонтированных в контейнер, полезен docker compose up -d --force-recreate.
Вывод. «Команда restart выполнилась успешно» ничего не говорит о том, что именно она сделала. Reload (SIGHUP-класс) и рестарт (пересоздание процесса) — разные операции с разными гарантиями. Проверяйте результат по наблюдаемому состоянию: PID и время старта, слушающие порты, освобождённые ресурсы, — а не по коду возврата. Когда цель — сбросить накопленное состояние или поднять новый листенер, гарантию даёт только пересоздание процесса.