Легкого пути нет. Во-первых, это не имеет ничего общего с сетью : CLOSE_WAIT - это состояние, в которое дочерний процесс входит после ответа на пакет FIN с помощью ACK и до закрытия сокета и отправки его равноправному пакету FIN . Во время состояния CLOSE_WAIT процесс завершает некоторую операцию, в конце которой он вызывает close (), которая заставляет ядро отправить пакет FIN.
Другими словами, во время состояния CLOSE_WAIT процесс пытается завершить некоторую операцию, не ожидая чего-либо от однорангового узла ; следовательно, закрытие сети, перезапуск интерфейсов и т. д. ничего не даст.
По большому счету, это не должно само по себе быть большой проблемой: нет ничего плохого в том, что некоторые процессы зависают в состоянии CLOSE_WAIT . Трудно понять, что вас беспокоит: вы заявляете, что родительский процесс прослушивает порт 11000, затем связывается с дочерним портом 37528, но вы утверждаете, что после смерти родительского процесса вы не можете запустить новый экземпляр сервера, поскольку порт 11000 не освобожден. Но вы только что заявили, что это не дочерний процесс, который его использует! Так кто же такой?
В любом случае, есть только несколько вещей, которые вы можете попробовать;
Вы пытались убить процесс с опцией -9 ? Это самое сильное, что вы можете придумать.
Вы можете использовать strace с самого начала для отслеживания системных вызовов даже в дочерних процессах (или это дочерние процессы?) С помощью
strace -f YourParentProcessЭто также будет следовать за процессами * fork () *.
Я предполагаю, что вы вполне можете забыть о ребенке и попытаться определить, почему и чем занят порт 11000. Вы должны попробовать более удобную команду
ss -lntp | grep 11000расследовать дело.