Имеется вопрос по сервисам в OS Linux (здесь и далее подразумеваю Ubuntu 18.04):
Обязательно ли сервис (микросервис) создавать как демон?
То есть — с двойным вызовом fork() в начале исполнения приложения?
Можно ли просто — как консольное приложение?
Создать демона не сложно, но есть проблема:
Подсистема логирования spdlog: https://github.com/gabime/spdlog
конфликтует с приложением-демоном, но при этом вполне нормально уживается с обычними "консольными"
Мне хотелось бы применять именно этот вариант логирования, так как он имеет много удобного и полезного функционала.
Здравствуйте, AlexGin, Вы писали:
AG>Доброе время суток, уважаемые коллеги!
AG>Имеется вопрос по сервисам в OS Linux (здесь и далее подразумеваю Ubuntu 18.04):
AG>Обязательно ли сервис (микросервис) создавать как демон? AG>То есть — с двойным вызовом fork() в начале исполнения приложения? AG>Можно ли просто — как консольное приложение?
Здравствуйте, уважаемый Zhendos, Вы писали:
...
Z>Можно, systemd (раз мы говорим о Ubuntu 18.04) сам обо всем позаботиться, Z>если указать нужный type (см. https://www.freedesktop.org/software/systemd/man/systemd.service.html), Z>и stdout/stderr он сам в логи кстати записывает.
Ну я так понимаю, что systemd мне поможет стартовать сервис.
Что же касается логов (а мне нужно не только "краши" и "ерроры" но и информацию о нормальной работе иногда видеть) — здесь будет spdlog.
Тем более, что его же я планирую применять и для GUI-шных утилит.
Здравствуйте, AlexGin, Вы писали:
AG>Здравствуйте, уважаемый Zhendos, Вы писали: AG>...
Z>>Можно, systemd (раз мы говорим о Ubuntu 18.04) сам обо всем позаботиться, Z>>если указать нужный type (см. https://www.freedesktop.org/software/systemd/man/systemd.service.html), Z>>и stdout/stderr он сам в логи кстати записывает.
AG>Ну я так понимаю, что systemd мне поможет стартовать сервис. AG>Что же касается логов (а мне нужно не только "краши" и "ерроры" но и информацию о нормальной работе иногда видеть) — здесь будет spdlog.
Ну если уже есть доступ к Linux машине то лучше прочитать: man 5 systemd.service
и посмотреть примеры в /usr/lib/systemd/system ,
там нужно где-то строчек пять написать и дать одну команду чтобы
ваш сервис стартовал при запуске.
AG>Обязательно ли сервис (микросервис) создавать как демон?
Уже повсеместно, в том числе в Ubuntu используется systemd, который сам умеет дважды форкаться. Т.е. ты пишешь обычное консольное приложение, а systemd запустит обертку, которая форкнется и запустит твое приложение. Более того, тот же systemd будет следить за приложением и, если оно упадет, то сможет перезапустить. Логи приложения, которое оно выдает на stdout/stderr, обертка systemd запишет в лог.
Короче, я уже даже и не знаю причины, зачем демону самостоятельно форкаться (а также менять work_dir, переоткрывать stdin/out/err и чего там еще делает демон кроме форка). Когда твоя программа — системный демон, это настраивается в конфиге systemd, а во время отладки эти форки и не нужны вовсе.
Здравствуйте, уважаемый Reset, Вы писали:
R>Уже повсеместно, в том числе в Ubuntu используется systemd, который сам умеет дважды форкаться. Т.е. ты пишешь обычное консольное приложение, а systemd запустит обертку, которая форкнется и запустит твое приложение. Более того, тот же systemd будет следить за приложением и, если оно упадет, то сможет перезапустить. Логи приложения, которое оно выдает на stdout/stderr, обертка systemd запишет в лог.
+100500
Да, я в курсе всего этого.
R>Короче, я уже даже и не знаю причины, зачем демону самостоятельно форкаться (а также менять work_dir, переоткрывать stdin/out/err и чего там еще делает демон кроме форка). Когда твоя программа — системный демон, это настраивается в конфиге systemd, а во время отладки эти форки и не нужны вовсе.
Я также не знаю причины, которая бы мешала не сегодня применять обычное консольное приложение в качестве демона.
Но на всякий случай, мне хотелось удостовериться в этом (чтобы по возможности исключить какой-либо нежданчик).
Здравствуйте, Reset, Вы писали:
R>Короче, я уже даже и не знаю причины, зачем демону самостоятельно форкаться (а также менять work_dir, переоткрывать stdin/out/err и чего там еще делает демон кроме форка). Когда твоя программа — системный демон, это настраивается в конфиге systemd, а во время отладки эти форки и не нужны вовсе.
Чтобы запускаться на других юниксах и на линуксах без systemd.
R>>Короче, я уже даже и не знаю причины, зачем демону самостоятельно форкаться (а также менять work_dir, переоткрывать stdin/out/err и чего там еще делает демон кроме форка). Когда твоя программа — системный демон, это настраивается в конфиге systemd, а во время отладки эти форки и не нужны вовсе.
vsb>Чтобы запускаться на других юниксах и на линуксах без systemd.
Расскажи реальный практичный конкретный пример, когда это нужно (разработка под Астру — это для меня не реальный случай, поддержка RedHat5 тоже за гранью реальности).
Ну, т.е. исключения бывают из любого правила, но я практик и для меня сейчас двойной форк выглядит, как задротство старперов из академической сферы, которые не способны адаптироваться к реальности. Gentoo без systemd или какой-нибудь Devuan — задротство в чистом виде. Впрочем, расскажешь реальный пример нужности двойного форка — сменю мнение (я гибкий).
P.S. Я пропустил по началу "на других юниксах". Из других юниксов для меня нечто практически полезное разве что экзотика в виде AIX или что там еще делают в IBM и MacOS. Солярка — маргинальщина и сдохнет скоро вместе со спарками, чпукс уже сдох, других даже не знаю (даже если за работу с ними платят нормальные деньги — валить оттуда нужно как можно скорее). Очень сомневаюсь, что один и тот же демон будет работать на Linux и чем-то из этого. Да и разработчик под такие OS вопросы задавать не станет (особенно, когда других вариантов и нет вовсе).
AG>Я также не знаю причины, которая бы мешала не сегодня применять обычное консольное приложение в качестве демона. AG>Но на всякий случай, мне хотелось удостовериться в этом (чтобы по возможности исключить какой-либо нежданчик).
Забыл написать, что твой консольный демон, все же должен обрабатывать сигналы для нормального завершения процесса: SIGHUP, SIGTERM, SIGQUIT (даже, если ему запрос на завершение работы будут присылать как-то еще, командой через сокет, например). Все-таки это не простое консольное приложение.
R>Расскажи реальный практичный конкретный пример, когда это нужно (разработка под Астру — это для меня не реальный случай, поддержка RedHat5 тоже за гранью реальности).
А что не так с Астра Linux, в текущей версии там systemd?
Здравствуйте, уважаемый vsb, Вы писали:
vsb>Чтобы запускаться на других юниксах и на линуксах без systemd.
1) Задачи охватить все версии UNIX & Linux — не ставиться.
2) Если бы всё-таки подобная задача стояла, то (подозреваю) данный вопрос оказался бы "вишенкой на торте".
3) Как я понимаю, все популярные современные дистры Linux всё-таки используют подсистему systemd.
Здравствуйте, Reset, Вы писали:
R>Забыл написать, что твой консольный демон, все же должен обрабатывать сигналы для нормального завершения процесса: SIGHUP, SIGTERM, SIGQUIT (даже, если ему запрос на завершение работы будут присылать как-то еще, командой через сокет, например). Все-таки это не простое консольное приложение.
Мне нужено логирование — по дням, когда каждому дню будет соответствовать свой лог-файл.
Посему, тот вариант применения spdlog, который указан в Вашей ссылке, не подходит.
P.S. До отправки первоначального сообщения имело место:
a) Советование с коллегами по работе;
b) Поиск в гугле примеров по spdlog и их выполнение
c) Обнаружение НА ПРАКТИКЕ проблемы
d) Гугление на тему имеющейся проблемы (а не сферический запрос в ваккуме) — выявившее
действительное наличие данной проблемы:
...spdlog does not support multi process. I dont think there is a quick workaround
Вот здесь: https://github.com/gabime/spdlog/issues/166
e) Практическое опробование решений по данной проблеме (которые, кстати, и не прошли)
f) Применение библиотеки spdlog в моих собственных небольших (тестовых) проектах.
Здравствуйте, Reset, Вы писали:
vsb>>Чтобы запускаться на других юниксах и на линуксах без systemd.
R>Расскажи реальный практичный конкретный пример, когда это нужно (разработка под Астру — это для меня не реальный случай, поддержка RedHat5 тоже за гранью реальности).
RHEL 6 тоже на system v init.
R>Ну, т.е. исключения бывают из любого правила, но я практик и для меня сейчас двойной форк выглядит, как задротство старперов из академической сферы, которые не способны адаптироваться к реальности. Gentoo без systemd или какой-нибудь Devuan — задротство в чистом виде. Впрочем, расскажешь реальный пример нужности двойного форка — сменю мнение (я гибкий).
Ну я рассказал для полноты информации. А то для кого-то и за пределами Windows жизни нет.
R>P.S. Я пропустил по началу "на других юниксах". Из других юниксов для меня нечто практически полезное разве что экзотика в виде AIX или что там еще делают в IBM и MacOS. Солярка — маргинальщина и сдохнет скоро вместе со спарками, чпукс уже сдох, других даже не знаю (даже если за работу с ними платят нормальные деньги — валить оттуда нужно как можно скорее). Очень сомневаюсь, что один и тот же демон будет работать на Linux и чем-то из этого. Да и разработчик под такие OS вопросы задавать не станет (особенно, когда других вариантов и нет вовсе).
Здравствуйте, AlexGin, Вы писали:
AG>Обязательно ли сервис (микросервис) создавать как демон? AG>То есть — с двойным вызовом fork() в начале исполнения приложения? AG>Можно ли просто — как консольное приложение?
Вообще и для демона двойной форк много лет как не нужен. Он был нужен, когда процесс, который лидер сессии, не имел терминала и при открытии терминала автоматом получал этот терминал как управляющий.
Не знаю, сколько лет назад это наконец убрали из Linux, но точно больше 10.
Сейчас и для явного демона достаточно fork + setsid.
AG>Вот подробнее: AG>https://github.com/gabime/spdlog/issues/166 AG>при этом — даже если создание "логгера" происходит после перехода в режим демона — приложение крашиться.
Перед форком полностью закрыть лог, после форка переоткрыть с нуля.
У нас такая же проблема с log4cplus. Увы, продвинутые логгеры они такие, диверсионные.
AG>Товарищи (наши разработчики) мне подсказывают: AG>-Просто сделать "консольку" и не заниматься "демоном"! AG>Правильно ли такое решение?
Вполне. Демонизацию вам может обеспечить и внешнее средство.
Есть systemd (уже говорили), есть другие переходники для демонов, есть screen
Здравствуйте, уважаемый netch80, Вы писали:
... N>У нас такая же проблема с log4cplus. Увы, продвинутые логгеры они такие, диверсионные.
Да, с моим старым простым файловым логером — этих проблем не было,
но и функционал там весьма ограниченный —
простое ежедневное логирование (имя файла формируется по текущей дате).
...просто сделать "консольку"... N>Вполне. Демонизацию вам может обеспечить и внешнее средство. N>Есть systemd (уже говорили), есть другие переходники для демонов, есть screen
+100500
Меня прежде всего интересует вышеупомянутый функционал: ежедневное логирование, когда имя файла формируется по текущей дате.
По старту — подготавливаем ежедневное логирование:
// Create a daily logger - a new file is created every day on 1:10amauto logger = spdlog::daily_logger_mt("daily_logger", "logs/daily.txt", 1, 10);
logger->set_level(spdlog::level::info);
logger->flush_on(spdlog::level::info);
spdlog::set_default_logger(logger);
Предполагается, что это серверное приложение (загрузили — и на неделю "забыли").
Что же мне в этом случае даст лог на "экране"?
P.S. Впрочем — библиотека spdlog достаточно гибкая и многофункциональная,
для настольных приложений — я могу выбоать любой (более подходящий) вериант логера
При этом в кодах проекта — строки, использующие логирование, не меняются!
Здравствуйте, AlexGin, Вы писали:
AG>Предполагается, что это серверное приложение (загрузили — и на неделю "забыли"). AG>Что же мне в этом случае даст лог на "экране"?
Кому вопрос-то? Я не предлагал писать лог на экран, хотя при крошечных объёмах это вполне вариант. Я говорил, что внешние аналоги демонизации могут быть самыми разными.
А логгирование stdout/stderr имеет независимый смысл — фиксация хода/проблем общего функционирования приложения.
AG>P.S. Впрочем — библиотека spdlog достаточно гибкая и многофункциональная, AG>для настольных приложений — я могу выбоать любой (более подходящий) вериант логера AG>При этом в кодах проекта — строки, использующие логирование, не меняются!
И что? Это много где так (тот же набивший оскомину log4cplus).
Вот я посмотрел на ваш spdlog... извините, это, мягко говоря, не готово к серьёзному применению:
1. Уровней логгирования тупо недостаточно. Как минимум, пропущен notice (должен быть между info и warning) — это уровень, на который должны реагировать роботы, но ещё не обязательно человек (в отличие от warning, который должен просматриваться админом периодически).
Ладно, в log4cplus такого тоже нет. Но там уровни идут с шагом 10000, и можно свои промежуточные ввести. Тут — info=2, warn=3, встроиться негде.
Точно так же, для серьёзного применения нужно несколько уровней дебага (минимум 3) и трассировки (минимум 2).
Здравствуйте, Reset, Вы писали:
R>Расскажи реальный практичный конкретный пример, когда это нужно (разработка под Астру — это для меня не реальный случай, поддержка RedHat5 тоже за гранью реальности).
