2011-02-28 3 views
1

У меня есть сценарий, который используется для повторного развертывания нескольких программ в настраиваемой серверной среде (т. Е. Не установленный стандартный контейнер с горячим отключением кода). Для этого он обрабатывает серверные процессы, но для полного закрытия всех их соединений требуется некоторое время. Это не дочерние процессы perlscript. Они работают в течение сотен дней в то время как обычно, поэтому я бы предпочел не включать процессы сервера в perlscripts, так что я могу разветвить их, чтобы закрыть их элегантно месяцев или лет спустя.Perl, ожидающий выхода из не-дочернего процесса

Так что в настоящее время ждать их смерти во время передислокации, я разбираю вывод ps -ef, захватывая поле pid, убивая этот pid, ожидая 60 секунд (что кажется разумным временем с этими процессами), перепроверяя ps -ef, чтобы убедиться, что они мертвы и т. Д. Продолжайте с копиями, chmods и т. Д.

Это решение кажется мне хромым/неуклюжим. Я google'd повсюду и ничего не видел по этой теме; есть куча материала о ожидании раздвоенных детей, и ожидание было бы идеальным, если бы оно действовало именно таким образом.

От чтения How to wait for exit of non-children processes (что соответствует c) Я предполагаю, что действительно не так много, что я могу сделать, кроме чтения/proc/pid, но я подумал, может быть, там будет решение, зависящее от perl где-то. Есть идеи?

ответ

4

Вы можете использовать kill 0, $pid (возвращает 1 на успех и 0 при сбое) вместо перепроверки ps -ef, но у этого есть возможная возможность, чтобы pid мог быть повторно использован.

Если у вас уже есть ps-синтаксический код, вероятно, его не стоит переключать, но есть Proc::ProcessTable.

Кроме этого нет идей.

+1

Другой Гоча является то, что с помощью убивать () для отправки сигнала, даже сигнал 0, подчиняется разрешениям Unix. Так, например, выполнение kill (0, 123) в скрипте Perl, выполняемом вашей учетной записью пользователя, где идентификатор процесса 123 принадлежит root, приведет к ложному (0) возврату, несмотря на то, что идентификатор процесса 123 жив и Что ж. –

+2

@John Siracusa: Я предполагал, что у него были права на убийство, но если нет, вы все равно можете определить, существует ли процесс, проверяя 'kill (0, $ pid) || $! ! = ESRCH' – ysth

+0

Спасибо за входных парней, я рад, что я не пропустил какую-то очевидную «серебряную пулю». «Убивать 0, $ pid' при проверке errno отлично работает. – Decker

0

В Unix \ Linux только родительский процесс получает сигнал, когда процесс выходит из родительского процесса. Это функция ОС, а не язык.

Другие решения будут эквивалентны с вашими - проверка таблицы процессов для существования процесса (хотя конкретный способ может изменяться - как с помощью пс или непосредственно запрашивая ядро)

+0

Да, я подумал, что, возможно, кто-то написал что-то вроде библиотек интеграции с java-сайтами где-то с какой-то интеграцией ОС, которую я мог бы использовать. Спасибо за помощь! – Decker

Смежные вопросы