Перезапуск при SIGSEGV

backtrace

ЕМНИП в обработчике сигнала там будет мусор. Для сбора дампа в таком состоянии есть библиотека Google Breakpad, которая написана с учётом правил обработки сигналов.

fork() с последующим execve() должен работать. Но мне кажется, что fork() здесь не обязателен. Так ли это?

Я не уверен, что эти функции будут работать в обработчике сигнала. Увы. И всё же, можно погуглить, как firefox запускает новый процесс после креша. Там должен быть ответ и на этот вопрос.

Конкретика по бэктрэйсу выходит за рамки темы.

man 7 signal говорит, что fork() и execve() безопасны для использования в обработчике сигнала.

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

пусть сохраняет core файл. перезапуск лучше делать инитом или в крайнем случае по крону.

http://habrahabr.ru/post/129207/ но согласен с предыдущим оратором

перезапуск лучше делать инитом

Как конкретно вы предлагаете это сделать из программы? О monit и других службах мониторинга давайте не будем.

И всё же, можно погуглить, как firefox запускает новый процесс после креша

Банально, /usr/bin/firefox - это скрипт, который запускает бинарник и проверяет его код возврата.

Как конкретно вы предлагаете это сделать из программы?

если программа словила SIGSEGV - не самая лучшая идея рестартовать её из самой себя.

всего 2 вопроса: 1) что делать если sigsegv придёт до установки обработчика сигнала ? 2) что делать если после установки обработчика перманентно случается sigsegv?

ЕМНИП в обработчике сигнала там будет мусор.

отнюдь

1) что делать если sigsegv придёт до установки обработчика сигнала ? 2) что делать если после установки обработчика перманентно случается sigsegv?

писать прямыми руками

Банально, /usr/bin/firefox - это скрипт, который запускает бинарник и проверяет его код возврата.

true way.

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

в системд это будет выглядить так:

[Service]
Restart=on-abort

If set to on-abort, the service will be restarted only if the service process exits due to an uncaught signal not specified as a clean exit status.

демоны запускаются инит скриптом... они пусть и следят

вы меня очень разочаровываете

Банально, /usr/bin/firefox - это скрипт, который запускает бинарник и проверяет его код возврата.

true way

Банально и правильно, да. Но ведь и fork + execve тоже достаточно просто. Я вообще спрашивал о необходимости fork здесь.

вообще поведение системных вызовов в обработчике сигналов, особенно с поврежденной кучей или стеком, не всегда предсказуемо и стабильно. записали бэктрейс и будьте счастливы, освобождайте память. иногда можно и запись не получить, а скрипт может дать 2>&1 и код возврата прямо в лог, что есть гуд в решении особенно противных ситуаций

Можно делать на цепочке форков. Watchdog -> KeepAlive -> Daemon. Как только процесс daemon завершается, сразу аккуратно завершается процесс KeepAlive и посылает сигнал SIGCHLD на watchdog. Параллельно какой-то из процессов может проверять /proc/PID

Немного сложно и малость многоресурсно, но весьма надежно.

Можно просто execv, без fork. Тогда даже pid тот же останется.

Банально и правильно, да. Но ведь и fork + execve тоже достаточно просто.

Это не просто если учитывать все нюансы этой последовательности. Например, незакрытые файловые дескрипторы после exec, мб ещё чего будет.

Можно просто exec прямо в обработчике. Но надо учесть, что сегфолт не от скуки прилетает. Не самая редкая причина — переполнение буфера, может затереть оригинальные аргументы командной строки и переменные окружения. Можно перезапускать с пустыми или с некоторыми захардкоженными в константных строках. Но тогда надо предусмотреть какое-то разумное поведение демона, когда он будет так запущен.

Самостоятельный перезапуск ненадежен, т.к. при некоторых фейлах даже fork() не успеешь вызвать. Так что только слежение и перезапуск извне.

Ты нас тоже. Перезапуск самостоятельный не надежен, и это в компетенции системы инициализации или вотчдогов. Демон может не освободить дескрипторы, локи. Выше уже упоминали другие потенциальные проблемы. Такой код я бы не пропустил в проект.

И всё же, можно погуглить, как firefox запускает новый процесс после креша.

что там гуглить? Открой run-mozilla.sh

Банально, /usr/bin/firefox - это скрипт

ВНЕЗАПНО: уже нет.

ВНЕЗАПНО: уже нет.

λ desktop ~ → file $(which firefox)
/usr/bin/firefox: symbolic link to `../lib/firefox/firefox.sh'

ЕМНИП в обработчике сигнала там будет мусор. Для сбора дампа в таком состоянии есть библиотека Google Breakpad, которая написана с учётом правил обработки сигналов.

Что за ерунда? Делаешь обработчик, принимающий контекст

В описанной тобой ситуации fork просто лишний. Если хочешь сделать rexec - делай сразу из обработчика сигнала. Но единственное надежное решение - fork до начала выполнения функций демона на рабочий процесс и сторожа, немедленное завершение рабочего процесса по сигналу, и перезапуск рабочего процесса сторожем.

Запускай два процесса.

+1

А перед exec еще и prctl(PR_SET_PDEATHSIG) навесить, чтобы убийство watchdog'а убивало и воркера.

Я бы за перезапуск из обработчика расстрелял бы например.

Есть же православный daemon, который все с удовольствием сделает за вас. Зачем использовать что-то еще?

Далее нам нужно прекратить выполнение процесса, и, желательно, перезапуститься

И опять получить SIGSEGV? Может, стоит починить это?

Если тебе хочется, чтобы процесс обязательно перезапустился после падения, тебе стоит воспользоваться программами, которые следят за процессами. Таким функционалом обладает программа init, та самая, которая конфигурируется в /etc/inittab.

И опять получить SIGSEGV? Может, стоит починить это?

Не надо путать разработку и выпуск продукта. Понятно, что на стадии тестирования и отладки софта такие штуки не нужны.

И продолжить рабоnать с, например, попорченой памятью.. Лучше сделать watchdog или простенкий стартер который перезапускает приложение после выхода

Благодарю alex_custov, dib2, Moncruist, mashina, const86, tailgunner, pathfinder, vromanov за конкретику.