При использовании MPM worker запросы обрабатываются потоками, существующими в процессах.
От https://httpd.apache.org/docs/2.4/mod/worker.html
Один управляющий процесс (родительский) отвечает за запуск дочерних процессов. Каждый дочерний процесс создает фиксированное количество серверных потоков, как указано в директиве ThreadsPerChild, а также поток прослушивателя, который прослушивает подключения и передает их серверному потоку для обработки по мере их поступления.
В Linux процесс «содержит» потоки, то есть один PID может иметь несколько потоков, которые совместно используют память (среди других ресурсов) с другими потоками в этом PID.
На самом деле, Linux действительно заботится только о «задачах», не многопоточный процесс — это PID с контейнером один задача.
Когда вы корректно перезагружаете Apache, вы завершаете содержащий его процесс.
Здесь происходит то, что Apache заставляет каждый поток ждать, пока все потоки в содержащем процессе не завершатся, прежде чем перезапустить PID контейнера.
Итак, в вашем случае у вас есть один поток, содержащийся во всех процессах в этом списке, который все еще занят или каким-то образом застрял.
У вас есть несколько вариантов.
- Просто перестаньте ждать и перезапустите.
- Найдите проблемную ветку (возможно, ошибка в приложении) и исправьте ее.
1, легко. Добавьте параметр конфигурации GracefulShutdownTimeout со значением, которое является высоким, но не глупым. Скажем, 900 секунд. По умолчанию это бесконечно, что означает, что ваши потоки вечно ждут завершения вашего проблемного потока.
Основным недостатком этого является то, что вы сталкиваетесь с вероятностью запуска процесса в середине выполнения чего-то критического, что, в свою очередь, может привести к повреждению файла или тонкой поломке приложения.
У вас также есть шанс (исчезающе малый) завершить работу клиента на полпути обработки.
2, потребует от вас обнаружения потока, который застрял в списке рабочих процессов, а затем диагностики того, что делает соединение, но вы обязательно найдете то, что может быть недостатком дизайна, и вы сможете более уверенно объяснить поведение, прежде чем просто сдуть прочь проблемную ветку.
