неубиваемый сервис С++

while (true)..

goto

В чём проблема? Ну кроме того что это плохая идея так делать.

Напиши внутри while(true) {...}

while (true).

И пизда CPU…

А про это ТС создаст отдельный топик.

А ну да, лол, чё-т я не подумал =)

просто ступил

добавил в while sleep_for, чтобы не убивать ЦПУ )

да ладно, сейчас даже на последнем куркуляторе больше одного ядра. один убил - 7 осталось.

Зачем? Пусть диспетчер служб этим занимается. Заодно в нем дополнительно настроить реакцию на падение (с какой задержкой перезапускать, сообщить мониторингу и т.д.)

диспетчер служб

Кто сказал systemd?

И пизда CPU…

Он же не будет бесконечно в этом цикле крутиться, основная работа будет в myservice.run();

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

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

Это будет делать деструктор MyService, который вызывается при вызове throw и раскрутке стека.

Это будет делать деструктор MyService, который вызывается при вызове throw и раскрутке стека.

Это если все написано в идеальном RAII. А если чел спрашивает как перезапустить службу в цикле, то идеальный RAII он может и не написать. Файлик какой-нить или соединение не закроет, буфер на отпустит и так далее. вот на этот предмет и надо вопрос перезапуска службы ему и продумать. Потому что главные проблемы с перезапуском будут тут, а не в том, как цикл написать.

Это если все написано в идеальном RAII. А если чел спрашивает как перезапустить службу в цикле, то идеальный RAII он может и не написать. Файлик какой-нить или соединение не закроет

Не надо давать вредные советы по написанию говнокода. RAII должен работать. Файлами и соединениями можно владеть через std::unique_ptr, там можно указать свою функцию-деструктор если надо.

Не надо давать вредные советы по написанию говнокода.

а если сам деструктор вызовет исключение?

а если сам деструктор вызовет исключение?

А если закрытие файла/соединения даст ошибку? Ручной вызов вам не поможет.

Может стоить выяснить, почему сервис падает прежде чем его перезапускать? Если падение не штатная ситуация.

А если закрытие файла/соединения даст ошибку? Ручной вызов вам не поможет.

Я про деструктор спросил вообще-то. Чистка ресурсов может быть достаточно сложной в общем случае, и затрагивать не только ресурсы занятые службой, но и состояние окружения. допустим 10 разных служб запущены одновременно, и все они как-то взаимодействуют между собой. крах одной службы может привести к проблемам в других. сама упавшая служба не может собственными силами устранить проблемы в других. То есть (в общем случае) при падении одной компоненты вся система приходит в состояние пертурбации из которой надо вылезать, приводить систему в корректное состояние, и перезапускать службу. вот на это и надо обратить внимание. и если падшая служба не может восстановить своими деструкторами, которые сами не должны порождать исключений, состояние системы, это надо делать явным образом,например в блоке catch.

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

Как в этом поможет вынос кода освобождения из деструктора? Этот код по прежнему может давать исключения.

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

Тогда она должна понести за собой другие службы, вызывая их деструкторы.

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

Не понимаю чем место расположения кода освобождения ресурсов влияет на его простоту и надёжность.

Может стоить выяснить, почему сервис падает прежде чем его перезапускать? Если падение не штатная ситуация.

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

man signal & fork :)

И пизда CPU…

В обработчик эксепшена что-то типа:

timeout = MIN(timeout + 1, 10);
sleep(timeout);

[Unit]
Description=...

[Service]
ExecStart=...
Restart=always

Как вариант? Ну и у доцкера с кубернетесом наверняка есть свои решения

А сам сервис пусть падает.

Не забудь ещё SIGSEGV перехватывать, ну и до кучи - спать неприрываемым сном в ядре.

у меня была похожая задача для работы с impinj считывателем через java sdk.
вот реально пофигу почему там что-то упало.
просто в цикле ходил по листу тредов и опрашивал их на предмет работоспособности.
потому, что их реализация llrp могла сломаться в любой момент, или словить дисконнект произвольно или вообще что угодно, что не имеет значение и не зависит от меня.

bool run = true;
while (run)
{
  try {
	try
	  {
		MyService myservice;
		myservice.run();
	  }
	catch(const std::exception &e)
	  { log(CRITICAL) << e.what() << std::endl; }
	catch(...)
	  { log(CRITICAL) << "Unknown exception" << std::endl; }
  } catch (...) {
     // logging exception shouldn't pass
  }
}

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

Не останавливайся на достигнутом, разворачивай в кубернетесе

Кто сказал systemd?

Ой, да хоть виндовый диспетчер служб. Лишь бы не кривые самописные костыли.

Так делать нельзя. Например, если у тебя кинеться эксепшен bad alloc, то непонятно как из этого состояния выходить. А если у тебя будет происходить запуск -> эксепшен -> повторение цикла, то ты еще и кучу CPU сожрешь, больше чем обычный бизи луп.

Ненужно 1: вылет с необработанным эксепшном не подразумевает корректного сброса состояния - поэтому проще тупо делать exec(argv)

Ненужно 2: его за вас сделает systemd