Как вы добиваетесь отказоустойчивости ваших приложений

Minix посмотри.

Это все не поможет, если серверу выключат свет.

UPS.

PID файл
скрипт
крон с минутным интервалом

Госпади.

while true do programm; done;

Госпади, ламеры.

/etc/inittab

respawn

Да, протянет некоторое время, но не факт, что его хватит. Тут скорее вопрос насколько важна постоянная работа приложения. Прокси-сервер не выглядит, как критически важное приложение. Для таких хостинг в дата-центрах, желательно в разных концах света, чтобы одним землетрясением не накрыло + лоад-балансер, это разумеется, в придачу к автоматическому перезапуску при падении. Хотя поллинг в 1 минуту подсказывает мне, что не так важна работоспособность этого сервера, что бы делать какие-то допольнительные телодвижения.

monit давно написан

Вам нужно что бы ваш сервер, маленький прокси или echo сервер работал всегда. Вы разработчик этого софта. Что вы предпримите.

1. поставить два(три и более) сервера

2. курить маны про балансировку нагрузки и репликацию.

Повесил этот скрипт в крон с минутным интервалом.

а для таких как ты придумали systemd.

Не уж то и друге так делают. А если нет, то как ?

раньше такие костыли делали, сейчас есть мегакостыль systemd для этой цели.

runit

Да, это один из возможных подходов, всё правильно делаешь.

1. поставить два(три и более) сервера

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

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

если в программе есть бага, то надо искать эту багу, а не костылять watchdog'и.

systemd же

Многое зависит от того, какой степени надежности хотелось бы добиться. Вариант с PID используется, но где гарантия, что ваше серверное приложение просто не зависнет?

Еще можно само серверное приложение научить оповещать других о том, что оно в рабочем состоянии. А дальше собственная фантазия: SNMP на специальную внешнюю аппаратуру, которое уже оповестит персонал в случае возникновения проблемы; дублирующий сервер (даже, возможно, на физически другой машине) по принципу master-slave, ожидающий того, что не придет сигнал alive по внутреннему своему протоколу (тут много тонкостей); скрипт-прибивалка-запускалка, ожидающий такого же события и т.д.

Вообще, тема непростая. Я был сопричастным когда-то, но в детали особо никогда не вдавался, поскольку было неинтересно.

если в программе есть бага, то надо искать эту багу, а не костылять watchdog'и.

Багу можно искать вечно, особенно если она в 3rdparty. Например, я уже больше года бьюсь с разрабами libevent'а по поводу bufferevent_openssl, а воз и ныне там. Спасает только watchdog.

Да, протянет некоторое время, но не факт, что его хватит.

Его хватит чтоб корректно завершить работу приложений и сделать шатдаун. Больше от него ничего и не надо. Если даже в часы X нужна работа серверов man дизельный генератор, дизельные подстанции

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

Как вы добиваетесь отказоустойчивости ваших приложений?

Мы просто сразу пишем их без ошибок же!!!!1111

Пара процессов, родитель форкуется и следит за потомком - если тот завершился по сигналу или с ненулевым кодом, то перезапукает его.

Багу можно искать вечно, особенно если она в 3rdparty.

ТС ясно сказал:

Мой софт

Например, я уже больше года бьюсь с разрабами libevent'а по поводу bufferevent_openssl, а воз и ныне там. Спасает только watchdog.

согласись - что-то тебя там держит, ибо ты давно-бы уже на них махнул рукой?

согласись - что-то тебя там держит, ибо ты давно-бы уже на них махнул рукой?

Держит. Проблемный софт работает на ~1500 серверов из них ~60 с включенным openssl. На этих ~60 он сегфолтится из-за libevent'а раз в неделю в среднем. У меня уже готов рабочий boost::asio backend, который работает стабильно и в случае использования ssl, но это слишком глобальное изменение, как мне кажется, в данном случае использование watchdog'а является меньшим из зол.

На этих ~60 он сегфолтится из-за libevent'а раз в неделю

что там с libevent ты разобрался? Может патч напишем?

что там с libevent ты разобрался? Может патч напишем?

Я несколько дней потратил только на написание минимального примера с проблемой. Там очень сложный баг, в момент падения стек испорчен, отлаживаться надо с debug логгированием. Дорого получается.

В общем суть там в том, что когда evhttp ходит через https и вдруг начинают возникать таймауты, то в некоторых (!) случаях происходит обращение по левому (удаленному?) указателю и сегфолт.

Я несколько дней потратил только на написание минимального примера с проблемой. Там очень сложный баг, в момент падения стек испорчен, отлаживаться надо с debug логгированием. Дорого получается.

ИМХО watchdog'и костылять ещё дороже. Но тебе конечно виднее, ибо я такого случая не наблюдал. Может в этом и проблема? Баг проявляется в каком-то очень специфичном юзкейсе?

если приложение корректное, оно не отказывает

КО

Секреты создания неубиваемых программ на C++

Перепиши его на erlang

/thread

Повесил этот скрипт в крон с минутным интервалом.

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

Сервис не должен падать. Никогда.

Перехватывай все сигналы, обрабатывай исключения. Сделай «безопасный» конфиг - в смысле, если исключения, то значения по-умолчанию.

Профилирование, работа под невозможной нагрузкой.

Шардинг, распараллеливание, безопасные секции/мютексы, репликация, резервирование, логирование и мониторинг, перехват и обработка исключений. ИТД...

Пара процессов, родитель форкуется и следит за потомком - если тот завершился по сигналу или с ненулевым кодом, то перезапукает его.

Молодец! Вы открыли метод циклического нуля!

Мы просто сразу пишем их без ошибок же!!!!1111

+1

Методику М.Джексона используем.

«Каждая найденная ошибка является предпоследней».

Да ты оптимист, как я погляжу.

Не-не. Как известно, программирование является процессом внесения ошибок в программу. Поэтому единственный Ъ путь - писать программу сразу без ошибок и больше ее не трогать.

А на что конкретно обратить там внимание? Я в принципе не знаком с этой OS.

Не знал что initd и systemd умеют (в том числе нужны для) мониторить рабоспособность процесса.

Варианты типа monit и runit отпали само собой так как на нашей старенькой CentOS их просто нету в репах. Тащить их из вне, никто не будет так как наших стареньких центосов целый зоопарк. И как всегда надо быстро, очень быстро, но что бы работало всегда.

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

Думаю в тред ответили нормально, но не называй это отказоустойчивостью