Я запускаю сценарий perl на экране (я могу войти в систему и проверить вывод отладки). Ничто в логике сценария не должно быть способно убить его до такой степени.
Я один из двух человек, имеющих доступ к серверу, и другой парень клянется, что это не он (и у нас обоих довольно много денег на этом, продолжая работать без сучка и задоринки). У меня нет оснований полагать, что хакеру удалось получить оболочку или что-то в этом роде. У меня очень мало причин подозревать администраторов в работе хоста (с точки зрения пропускной способности / процессора, этот скрипт довольно легкий).
Экран продолжает работать, но в конце вывода perl-скрипта я вижу «Killed», и он возвращается к приглашению. Как мне подойти к тестированию, что, черт возьми, бьет?
Я проверил crontab, там нет ничего, что могло бы убить случайные / неслучайные процессы. Ни в одном из файлов журнала нет никаких подсказок. Казалось бы, он будет работать от 2 до 8 часов (а на моем домашнем Mac он проработает без проблем более 24 часов). На сервере работает та или иная версия Ubuntu, я могу посмотреть, если это имеет значение.
Добавьте обработчики сигналов для всех сигналов (TERM, SEGV, INT, HUP и т. Д.) И пусть они выходят из системы при каждом попадании. Он не скажет вам, что посылает сигнал, но позволит вам увидеть, что это за сигнал, и, возможно, проигнорировать его.
$SIG{'TERM'} = $SIG{'INT'} = sub { print(STDERR "Caught SIG$_[0]. Ignoring\n"); };
Это будет распечатывать, когда он поймает sigterm или sigint, а затем вернет управление обратно программе. Конечно, если все эти сигналы игнорируются, единственный способ убить его - это завершить работу самой программы или отправить ей сигнал SIGKILL, который невозможно перехватить.
Я понимаю, что это не совсем ответ на заданный вами вопрос, поэтому прошу прощения, если это несколько не по теме, но: действительно ли ваше приложение должно работать постоянно, вечно? Perl - не самая ресурсосберегающая среда в мире, и хотя накладные расходы на запуск интерпретатора не лишены недостатков, очень долго выполняющиеся скрипты могут иметь собственные проблемы - утечки памяти, часто на уровне ниже вашего. , являются проклятием существования разработчика vanilla-perl, поэтому люди часто смягчают эти проблемы, либо работая в более формальной подсреде сохранения ресурсов, такой как Perl :: POE, либо передавая долго выполняющуюся часть прослушивателя задание для интерфейсной службы, такой как xinetd, и выполнение компонента perl только тогда, когда необходимо выполнить работу.
Я запускаю несколько сценариев perl, которые непрерывно читают и обрабатывают вывод нашего (довольно большого) центрального потока системного журнала; они страдают от ужасных, необъяснимых проблем «не освободил память, несмотря на обрезку хэш-ключей», и они находятся на пути к тому, чтобы быть обработанными чем-то, более подходящим для непрерывного ввода большого объема (очередь событий, такая как Gearman, например), так что мы можем оставить Perl для задач обработки данных, которые он лучше всего выполняет.
Это продолжалось немного; Я действительно сожалею. Надеюсь, это хоть немного поможет!
Системный журнал - это первое, с чем нужно проконсультироваться. Если этого недостаточно…
Вы не можете определить, кто посылает сигнал процессу. Это может быть другой процесс, это может быть ядро и т. Д. За исключением недавнего использования инфраструктуры perf, требуются некоторые догадки.
Однако вы можете настроить более качественный мониторинг. В atop package в debian / ubuntu настраивает службу, которая будет регистрировать загрузку системы и активность каждого процесса (диск, память, процессор). Затем вы можете просмотреть эти журналы и почувствовать, что происходило в момент сбоя процесса.
Ускоренный курс: sudo atop -r, переходите с помощью t и T, тип h чтобы получить помощь по различным визуализациям.
Также рассмотрите возможность добавления обработчика сигналов, который сбрасывает pstree во временный файл.
Без особых знаний, я бы начал смотреть в выводе dmesg или в различных системных журналах, если запущен OOM killer. Если так, то, наверное, так.
Вероятно, вы столкнулись с ограничениями ресурсов. Например процессорное время. Пытаться ulimit -a Проверять. Если это только мягкий лимит, установленный в сценарии входа в систему, вы можете исправить это, например, ulimit -t unlimited. Если это жесткое ограничение, как, например, для обычных пользователей OpenBSD и других ОС, вам придется переопределить.
Пока вы не решите проблему, запустите сценарий с
nohup scriptname
может помочь. Если по-прежнему происходит сбой, проверьте файл nohup.out.
И если ничего из упомянутого здесь не помогает, я бы попытался использовать strace / ltrace, чтобы увидеть, какие системные или библиотечные вызовы выполнял скрипт до сбоя, но они генерируют БОЛЬШОЙ вывод.
В предыдущей жизни я нашел компьютер DEC Ultrix, в котором была очень умная задача cron, которая искала все процессы с более чем 1 часом ЦП и убивала их. Вот почему еженощный пакетный отчет прекращался каждую ночь.
Какие-нибудь умные задания / скрипты cron, которые могут его убить? Или это может быть другой параметр настройки производительности или что-то вроде уже данного ответа ulimit.