Добрый день,

есть софтина на 200кб - САР сети. Скрипт проходит по 3000 железок и выверяет на них настройки.
До определённого момента всё работало нормально. В 9 потоков задача выполнялась за 3-4 часа.
После очередной доработки логики проверки конфигурации скрипт начал "заканчиваться" неожиданно.

Самое печальное, что заканчивается он без сообщений об ошибках, заканчивается в разных местах и работает разное время (от 1 часа до 7 часов). 

Помирает он не в момент максимальной нагрузки. В логах системы в момент смерти ничего нет.

Вопрос: как поймать момент выхода из скрипта и узнать откуда он выходит и почему?

Откатиться на старую версию не вариант, это приведёт к проблемам на сети несравнимым с вылетом скрипта.

попробуйте определить $SIG{__DIE__}.
Либо используйте Devel::Trace

Вот спасибо, Devel::Trace - то что надо.
О перехвате сигналов я думал, но там не факт, что сигнал приходит из вне. А вот вместе перехват сигналов +  Devel::Trace дадут искомый результат 

Я сделал жалкую подобию  Devel::Trace, первой строчкой в каждом методе идёт на вывод на экран названия процедуры и параметров при включеном внутреннем дебаге. Помогает разобраться с бизнеслогикой в случае кривой настройки оборудования.

лучше форкнуться 9 раз, получится надёжнее

Это сообщение отредактировал(а) noize - 9.9.2014, 17:04

Форкать неудобно, будет приходить 9 отчётов. А я собираю результаты и шлю на почту один общий отчёт.
У меня раньше было ещё более надёжно: шеловский скрипт вызывал несколько экземпляров моей софтины. Но там два неудобных момента - подготовить параметры для запуска довольно нетривиальная задача, силами баша решается с трудом, да и 9 отчётов читать лень.

Печаль, Devel::Trace сжирает всё свободное место на винте за час работы. Нужно писать по крону скриптик, который будет проверять наличие процесса в памяти и если он ещё там обнулять файл...

Ставлю на необработанный SIGPIPE

Добавлено через 3 минуты и 39 секунд
http://forum.vingrad.ru/act-ST/f-182/t-345963.html

После включения дебага скрипт перестал дохнуть... что печально.

Можно сводить данные из всех форков в один хеш с использованием IPC::Shareable

Ситуация до боли смешная. При включенной отладке скрипт работает. При запуске из консоли работает. При запуске по крону дохнет еженочно.
Сигналы никакие перехватить не удалось.

noize, спасибо, переписал на fork, ночью проверим. Форк оказался более предсказуемым и логи о варнингах доходить стали от потомков.

быть может потому, что при запуске из крона используются свои переменные окружения и при таких запусках всегда надо использовать абсолютные пути.

Можно ещё через strace подцепиться к процессу: strace -p pid
И последние 1000 строк, скажем, писать в файл. Типа

Часто по системным вызовам тоже можно обнаружить проблему.

noize, тут-то мы учёные с путями. fork`нутый скрипт запущенный из консоли не вылетел, ждём боевой прогон ночью.

Похоже что-то криво было в потоках...

Fork отработал ночью штатно. 
Помониторю на следующей недели как оно будет жить.

Это сообщение отредактировал(а) Secandr - 12.9.2014, 09:25

Скрипт работает стабильно.
Всем спасибо за помощь.