Не умирающая прога. (Прога которая в случа сбоя перезапускает саму себя.)

[sawerse]

Добрый день.
У меня появилось желание написать такую вещь.
Есть прога. В случае ошибки она слетает. Как можно сделать так что бы в случае не коректного завершения прога перезапускала саму себя?

Первые мои попытки не удались. Я пробовал перехватывать сигнал не коректого завершения проги и перезапускать ее.
Может кто то что то еще посоветует?

[sergeyvp]

Добрый день.
У меня появилось желание написать такую вещь.
Есть прога. В случае ошибки она слетает. Как можно сделать так что бы в случае не коректного завершения прога перезапускала саму себя?

Первые мои попытки не удались. Я пробовал перехватывать сигнал не коректого завершения проги и перезапускать ее.
Может кто то что то еще посоветует?

Можно написать скрипт который будет отслеживать состояние программы по pid и в случае чего перезапускать её.

А саму программу нельзя сделать непадающей? Исходники закрыты?

[divenvrsk]

перезапуск - это не "не умирающая", это подход так сказать новичка в программировании...
язык какой?
если ошибки в коде - то exception's и их обработка, если ошибки ОС или сторонних библиотек, то напишите скрипт и внутри перезапускайте рухнувшее сколько душе угодно.

[sawerse]

Это просто мысль навящивая.
Я пишу прогу с заведомыми ошибками.

[sergeyvp]

Я пишу прогу с заведомыми ошибками.

А смысл?

[drBatty]

Это просто мысль навящивая.
Я пишу прогу с заведомыми ошибками.

дык пиши на си - man fork. дочка сдохнет, папа перезапустит. Всего делов? Только объясни, что значет "слетает"?

[Denjs]

в бан его! в бан вирусописателя!
ща он нам тут понапишет программ которые kill-ом не грохнешь...

(^^)


А нельзя ли все-таки воздержаться от флуда в тематическом разделе? UT

[Liksys]

Это реально. Сам интересовался этим делом. Только реализация была на Python. Суть сводится к слежению родителем за потомком.
У меня была сделана более крутая реализация, суть которой сводилась к слежению за Python-воскими исключениями, перезапуске и переинициализации отдельных сбойных объектов и принудительной передаче управления функции сборки мусора. В принципе прога была неубиваемой в смысле внутренних сбоев. kill -9 ессно вырубал.
Относительно полностью неубиваемой штуки - это можно реализовать через "коэффециэнт злости", когда при попытке бить прогу рождается n+1 процессов)))) Но это из области UNIX-вирусов, в целях неплождения которых разглашать эту инфу я не буду

[drBatty]

в бан его!

меня, что ли? Сам ты вирусмейкер. Человек спросил решение задачи - я его дал, ну как мог, если неправильно - скажи в чём.

[Portnov]

В качестве примера подхода "слежение родителя за ребенком" см. на mysqld и mysqld-safe.

[nesk]

Даже программировать особо не надо.
Можно вообще скрипт написать

вот программа которая вываливается с ошибкой через минуту (err_prog.sh)

Код: Выделить всё

#!/bin/bash
MYPID=$$
echo "Start"
sleep 60
echo  "Stop with error"
kill -SIGSEGV $MYPID

вот программа которая её будет перезапускать (restart.sh)

Код: Выделить всё

#!/bin/bash
if [ -z $1 ]
   then
   echo "usage: $0 <filename>"
   exit 1
fi
if [ ! -x $1  ]
    then
    echo "$1 is not executable file"
    exit 1
fi

while true
do
$* && exit 0
echo "restart program"
done

запускаем:
./restart.sh ./err_prog.sh

вы этого хотели?

Это еще мелочи.
Можно вообще без программирование. Можно старого, доброго дедушку init попросить следить за нашей программой и перезапускать её.

bash

sudo echo "R9:2345:respawn:/sbin/err_prog.sh" >>/etc/inittab sudo init q ps -e | grep err_prog.sh

Только не надо забывать, что программа из-за ошибок может не только завершиться, но и зависнуть. И в этом случае перезапуск не поможет. Надо понять, что программа зависла, убить её и перезапустить.

[drBatty]

Только не надо забывать, что программа из-за ошибок может не только завершиться, но и зависнуть. И в этом случае перезапуск не поможет. Надо понять, что программа зависла, убить её и перезапустить.

в этом случае необходимо, что-бы программа регулярно изменяла какую-либо переменную(в bash можно время в какой-нибудь файл писать), и отслеживать изменения. Как только нет изменений - зависло - убиваем(перезапускаем).

[nesk]

в этом случае необходимо, что-бы программа регулярно изменяла какую-либо переменную(в bash можно время в какой-нибудь файл писать), и отслеживать изменения. Как только нет изменений - зависло - убиваем(перезапускаем).

Да, совершенно верно, можно так.
Хотя конечно это не единственный и может не самый оптимальный способ.
Можно попробовать реализовать обмен сигналами.
Короче надо написать простенький watchdog.
А с методом автор сам определиться

[Zeus]

А насколько "регулярно"?
Ветки алгоритма в общем случае могут быть непредсказуемой длины.

[nesk]

А насколько "регулярно"?
Ветки алгоритма в общем случае могут быть непредсказуемой длины.

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

[Portnov]

Менее переносимый, но более простой способ. В современных ядрах Linux (кажется, с 2.6.18) есть Hangcheck Timer. Который как раз и следит за работающими программами, в случае зависания - жалуется в консоль. В дебиане по дефолту сделан модулем. Настраивается при конфигурации ядра.

[drBatty]

А насколько "регулярно"?
Ветки алгоритма в общем случае могут быть непредсказуемой длины.

Не могут. Для любого алгоритма есть максимальное время его выполнения. Его всегда можно примерно определить. Пример: qsort() обычное время выполнения равно C1*n*log(n). Константу С1 примерно можно оценить прогнав сортировку на нескольких наборах данных. В худшем случае С2*n^2. Приэтом для qsort С1 примерно равно C2. Конкретно, мы отсортировали 1048576 элементов за 1сек. C1 примерно равна 1/20 000 000, в худшем случае время = 10^6*10^6/20/10^6 = 50 000 секунд. Если за 70 000 программа не завершилась - она зависла.

[Zeus]

Я же написал: "в общем случае"
Конечно у любого алгоритма - время выполнения конечно (по определению).
Но это не значит, что оно известно заранее.

[drBatty]

Я же написал: "в общем случае"
Конечно у любого алгоритма - время выполнения конечно (по определению).

Код: Выделить всё

for(;;);

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

Но это не значит, что оно известно заранее.

Конечно, если неизвестны входные данные. В моём примере известны: любой набор(их всего-то 2^1048576) из 1048576и элементов известной структуры. (есть ещё некоторые ограничения, к примеру если мы сортируем кирпичи, есть зависимость от веса кирпичей, таскать тяжёлые кирпичи дороже, т.ч. не все элементы доступны).

[Zeus]

Я же написал: "в общем случае"
Конечно у любого алгоритма - время выполнения конечно (по определению).

Код: Выделить всё

for(;;);

Время не конечно

Имхо, формально - это и не алгоритм.

Но это не значит, что оно известно заранее.

Конечно, если неизвестны входные данные. В моём примере известны

Так рассматривается-то не твой пример, а алгоритм "в общем случае".

у нас под рукой есть системный вызов alarm
пишем обработчик на сигнал SIGALRM и там даем понять сторожевому процессу, что мы еще живы.

Обработчик "даёт понять"?
Я думаю нужен контроль того, что алгоритм где-то не зациклился - обработчик-то чего проверять?

[nesk]

у нас под рукой есть системный вызов alarm
пишем обработчик на сигнал SIGALRM и там даем понять сторожевому процессу, что мы еще живы.

Обработчик "даёт понять"?
Я думаю нужен контроль того, что алгоритм где-то не зациклился - обработчик-то чего проверять?

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

[nesk]

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

[v04bvs]

А насколько "регулярно"?
Ветки алгоритма в общем случае могут быть непредсказуемой длины.

Не могут. Для любого алгоритма есть максимальное время его выполнения. Его всегда можно примерно определить. Пример: qsort() обычное время выполнения равно C1*n*log(n). Константу С1 примерно можно оценить прогнав сортировку на нескольких наборах данных. В худшем случае С2*n^2. Приэтом для qsort С1 примерно равно C2. Конкретно, мы отсортировали 1048576 элементов за 1сек. C1 примерно равна 1/20 000 000, в худшем случае время = 10^6*10^6/20/10^6 = 50 000 секунд. Если за 70 000 программа не завершилась - она зависла.

У qsort сложность в худшем случае квадратичная.

[drBatty]

Есть разница между зависшей программой и зациклившейся.
Я с самого начала имел ввиду зависшую, программу находящуюся в тупике (в deadlock)

Какая разница? В практическом смысле? Как отличить одно от другого?

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

Ага. Согласен.

[drBatty]

В худшем случае С2*n^2.

У qsort сложность в худшем случае квадратичная.

Ага, двойку стёр, спасибо. Я знаю про О большое. Но в данном случае речь идёт о времени, если при каждом разбиение множество делится на подмножество в 1 эл-т и подмножество в N-1 элемент(а не примерно поровну), время увеличивается примерно на N/log(N). Степень "примерности" достаточна для наших целей. В моём примере просто показано, что программа для пользователя "зависла"(кто будет ждать 50000 секунд, если обычно достаточно одной?!). Но это вполне нормальное поведение. Неожиданое даже для создателя программы.

[nesk]

Какая разница? В практическом смысле? Как отличить одно от другого?

Состояния процесса будут разные.
Думаю Hangcheck Timer будет ругаться только на процессы находящиеся в deadlock.
deadlock процессы не жрут cpu.

[drBatty]

nesk, deadlock это тупик, мертвая блокировка. когда два процесса друг-друга заблокировали. Я про бесконечные циклы, они, как раз, жрут время CPU. Как можно отделить бесконечный цикл от попросту долгого цикла(к примеру - поиск пороля перебором)? А если сцепятся два процесса в deadlock, разве не будут они постоянно проверять - не освободился ли ресурс.

[nesk]

nesk, deadlock это тупик, мертвая блокировка. когда два процесса друг-друга заблокировали. Я про бесконечные циклы, они, как раз, жрут время CPU.

да, да и я как раз говорил, что мы с вами имели введу разные вещи.
а потом Вы меня спросили: а есть ли разница между deadlock и зацикливанием.

Как можно отделить бесконечный цикл от попросту долгого цикла(к примеру - поиск пороля перебором)?

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

А если сцепятся два процесса в deadlock, разве не будут они постоянно проверять - не освободился ли ресурс.

Все зависит от реализации.
Вы имеете ввиду активное ожидание.
а можно подругому
процесс может спать до тех пор пока ресурс не освободиться, а потом его может разбудить программа-диспетчер ресурсов (ядро ОС, в частности)




Мы отвлеклись от темы топика
Автор не хотел убивать программу, он хотел её перезапускать, если она сама умрет.
Я придумал еще решение : можно в шеле ставить ловушку на SIGCHLD. А там смотреть если это умер наш процесс, то перезапустить его. Вот. Гы

[drBatty]

nesk, deadlock это тупик, мертвая блокировка. когда два процесса друг-друга заблокировали. Я про бесконечные циклы, они, как раз, жрут время CPU.

да, да и я как раз говорил, что мы с вами имели введу разные вещи.
а потом Вы меня спросили: а есть ли разница между deadlock и зацикливанием.

Как можно отделить бесконечный цикл от попросту долгого цикла(к примеру - поиск пороля перебором)?

бесконечный цикл - это цикл в котором либо вообще нет условия выхода, либо оно никогда не будет достигнуто.
Со стороны между длительным циклом и бесконечный цикл разницы нет.

при deadlock выполняется цикл ожидания выхода из цикла которого не будет.
for(;;);
это тоже цикл ожидания прерывания, которого не будет, если мы туда сможем впихнуть команду ожидания CPU(HALT) загрузки тоже не будет. Например поставить sleep(1). Поэтому взаимная блокировка для меня - частный случай бесконечного цикла.

А топикстартер уже наверно тестирует свой неубиваемый код. Хотяб написал, какую версию неубиваемости он применил... Про deadlock - в топик, может это и не смерть, но кома - точно