Perl: установка обработчиков сигналов в разветвленном дочернем элементе, который выполняет

Я нашел ответ в разделе Управление обработкой сигналов для демонов, которые fork() очень полезно для того, что я делаю. Я не уверен, как решить

«Поэтому вам нужно будет установить любую обработку сигналов в выполняемом процессе при его запуске»

Я не контролирую процесс, который запускается. Есть ли способ заставить некоторые дескрипторы сигналов на execed от родителя форка?

Изменить:{
Я пишу модуль Perl, который отслеживает длительные процессы. Вместо

system(<long-running cmd>);

ты бы использовал

my_system(<ID>, <long-running cmd>);

Я создаю файл блокировки для <ID> и не допускаю другого вызова my_system(<ID>...), если в данный момент выполняется файл с совпадающим идентификатором.

Родительский fork/execs <long-running cmd> находится в процессе очистки файла блокировки, когда он завершается. Я бы хотел, чтобы дочерний элемент был самодостаточным, чтобы родитель мог выйти (или чтобы дочерний элемент мог позаботиться о себе, если родитель получит kill -9).
}


exec fork perl signal-handling
person ajwood    schedule 01.04.2011    source источник

Ответы (2)


arrow_upward
2
arrow_downward

В системах Unix вы можете заставить исполняемый процесс игнорировать сигналы (если только процесс не решит переопределить то, что вы говорите), но вы не можете заставить его установить для него обработчик. Максимум, что вы можете сделать, это оставить соответствующий сигнал обработчику по умолчанию.

Если вы подумаете об этом, вы поймете, почему. Чтобы установить обработчик сигнала, вы должны предоставить указатель на функцию, но процесс, который выполняет exec(), не может указать одну из своих функций, потому что они не будут существовать как часть исполняемого процесса, и он не может указать один из исполняемых процессов функционирует, потому что они не существуют как часть исполняемого процесса. Точно так же вы не можете зарегистрировать обработчики atexit() в выполняемом процессе, которые будут выполняться исполняемым процессом.

Что касается вашей проблемы с программированием, есть веская причина, по которой файл блокировки обычно содержит идентификатор процесса (pid) процесса, удерживающего блокировку; это позволяет вам проверить, продолжается ли этот процесс, даже если это не ваш ребенок. Вы можете прочитать pid из файла блокировки, а затем использовать kill(pid, 0), который сообщит вам, существует ли процесс, и вы можете сигнализировать о нем, фактически не отправляя никакого сигнала.

person Jonathan Leffler    schedule 02.04.2011
comment
Отличный ответ. Я надеялся, что будет способ каким-то образом загрузить функцию обработчика в работающую программу... жаль, что это невозможно. Кроме того, эта схема для файла блокировки работает почти в моей ситуации все время. Единственная проблема заключается в том, что многие компьютеры используют файловую систему nfs. Таким образом, если есть блокировка, запущенная из A, у B нет возможности увидеть, работает ли она все еще или это зависший файл блокировки. - person ajwood; 02.04.2011

arrow_upward
1
arrow_downward

Одним из подходов было бы использование двух вилок.

Первая вилка создаст дочерний процесс, ответственный за очистку файла блокировки, если родитель умрет. Этот процесс также разветвит внука, который будет выполнять длительную команду.

person David Harris    schedule 01.04.2011
comment
Это действительно поможет? Вы все еще можете kill -9 сделать первый форк, чтобы все испортить. - person ajwood; 03.04.2011