Имеется вопрос по сервисам в 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 тоже за гранью реальности).
Здравствуйте, AlexGin, Вы писали:
AG>Мне нужено логирование — по дням, когда каждому дню будет соответствовать свой лог-файл.
Это умеет journald делать прямо из твоего stderr/stdout. Ну, точнее journalctl можно попросить вывести логи твоего приложения начиная с такойто датывремени и заканчивая этаким.
Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл. А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее.
unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Здравствуйте, Sheridan, Вы писали:
AG>Мне нужено логирование — по дням, когда каждому дню будет соответствовать свой лог-файл.
S>Это умеет journald делать прямо из твоего stderr/stdout. Ну, точнее journalctl можно попросить вывести логи твоего приложения начиная с такойто датывремени и заканчивая этаким.
Спасибо, уважаемый Sheridan, буду в курсе!
S>Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл.
И вот тут вот начинается самое интересное:
a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм,
позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
b) Переход на следующие сутки (и время переоткрытия суточного лога) — как уже упоминалось, каждые сутки — свой файл.
с) Возможность ведения одним процессом более чем одного файла лога (для больших проектов — это актуально).
d) Если в файл одновременно пишет несколько потоков исполнения, то поторебуется защитить вывод мьютексом.
e) Возможность асинхронного формирования лога — когда поток, запросивший логирование не ждёт окончания записи лог-файла.
Да, я (несколько лет назад) сделал свой велосипед, позволяющий вести многоптоточное логирование по нескольким категориям.
Но тем не менее, поизучав spdlog, пришёл к выводу — что эта библиотека намного удобнее и проработанее моего "лога".
S>А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее.
Ну то, что я хочу, можно выяснить простым текстовым редактором
S>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
+100500
Я в курсе понятия UNIX-way.
Однако, я не сторонник догм
S>>Если тебе нужен именно файл, то опять неправильный подход. Просто пиши в файл. AG> AG>И вот тут вот начинается самое интересное: AG>a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм, AG>позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
Реализуется за час гдето вместе с тестами.
AG>b) Переход на следующие сутки (и время переоткрытия суточного лога) — как уже упоминалось, каждые сутки — свой файл.
Это проблема logrotate, а не твоя. Ты зря потратил время.
AG>с) Возможность ведения одним процессом более чем одного файла лога (для больших проектов — это актуально).
Допустим что это нужно, чтото типа сайтов у nginx и про каждый сайт пишет лог в отдельный файл. Не вижу проблем. Просто когда открываем файл для дописывания — генерируем имя файла динамически.
AG>d) Если в файл одновременно пишет несколько потоков исполнения, то поторебуется защитить вывод мьютексом.
Достаточно дописывать и закрывать. И ждать пока открыт для записи.
AG>e) Возможность асинхронного формирования лога — когда поток, запросивший логирование не ждёт окончания записи лог-файла.
Оформи логгер в виде отдельного потока
AG>Да, я (несколько лет назад) сделал свой велосипед, позволяющий вести многоптоточное логирование по нескольким категориям. AG>Но тем не менее, поизучав spdlog, пришёл к выводу — что эта библиотека намного удобнее и проработанее моего "лога".
Да магистры с тобой, я не против. Просто лично я не вижу смысла в ручной ротации логов.
S>>А на файл натравливается logrotate, который по куче параметров умеет то что ты хочешь — файлы по дням/размеру/архивированное старое и так далее. AG>Ну то, что я хочу, можно выяснить простым текстовым редактором
Ты распарсил о чом я тут написал или ты решил что я про поиск чегототам?
S>>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ. AG>+100500 AG>Я в курсе понятия UNIX-way. AG>Однако, я не сторонник догм
Есть ещо примерно полтора землекопа таких. Жутко неудобно с их логами работать. Приходится извращаться.
Ну, например, мне надо чтобы логи ротировались не каждый день, а если превышают 128 мегабайт. И отротейченое чтобы сжималось. А автору было срать на эти хотелки и у него логи сами ротейтятся каждые сутки, не сжимается и размером каждый файл — сотни мегабайт. Приходится извращаться.
Здравствуйте, уважаемый Sheridan, Вы писали:
S>Реализуется за час гдето вместе с тестами.
Так никто и не спорит. Вопрос — зачем велосипедить?
S>Это проблема logrotate, а не твоя. Ты зря потратил время.
Я не тратил время и не изобретал велосипед. Я просто я взял это: https://github.com/gabime/spdlog
теперь просто творю и радуюсь моему выбору.
Насчет многопоточности — дискутировать не буду.
Делай, как считаешь нужным, но на всякий случай — приготовься к сюрпризам (для реализации без мьютексов).
S>Да магистры с тобой, я не против. Просто лично я не вижу смысла в ручной ротации логов.
+100500
Я также не вижу, когда для этого есть удобная библиотека (подключаемая в виде заголовочника).
S>Ты распарсил о чом я тут написал или ты решил что я про поиск чегототам?
Хорошо, этот самый spdlog умеет и syslog поддерживать. При этом, кроме настроек логгера, ничего не надо менять.
S>Ну, например, мне надо чтобы логи ротировались не каждый день, а если превышают 128 мегабайт.
И это также умеет spdlog, но для наших проектов ежедневный лог (как правило) много меньше 128 мегабайт.
S>И отротейченое чтобы сжималось. А автору было срать на эти хотелки и у него логи сами ротейтятся каждые сутки, не сжимается и размером каждый файл — сотни мегабайт. Приходится извращаться.
Ну так ведь spdlog позволяет гибко выбрать политику логирования.
Если сисадминам на стороне Заказчика не нравиться посуточная, то можно выбрать что-то более подходящее.
При этом — в кодах меняется одна строчка. Исключаются большие и долгие изменения.
P.S. Признаюсь, что именно вследствии заботы о конечных потребителях и их сисадминах я и перешел на spdlog.
Ранее сушествовавшая самоделка — не позволила бы учесть всё это.
Ну а так — я просто с удовлетворением констатирую тот факт что,
при помощи этой библиотеки сумею закрыть запросы требовательного Заказчика!
Здравствуйте, AlexGin, Вы писали:
AG>При этом — в кодах меняется одна строчка. Исключаются большие и долгие изменения.
Где-где меняется?
Ещо раз: лучший лог — в консоль или в один файл. Не беги впереди паравоза, не придумывай как облегчить жизнь админу. Как правило это заканчивается лишь усложнением жизни админу.
Здравствуйте, AleksandrN, Вы писали:
... AN>Есть функция daemon().
Спасибо за рекомендацию, но как раз с "демоном" — как войти в этот режим — проблем у меня не возникало.
Конфликт библиотеки логирования (это spdlog) в приложении типа "демон" — да, имеет место.
Остановился на том, что имеющаяся в OS Linux система запуска приложений systemd —
избавляет моё сервисное приложение от необходимости перехода в режим "демон" (просто оно в режиме "консоли").
В общем — теперь делаем простое CLI приложение и не паримся
Здравствуйте, Reset, Вы писали:
R>Ну, т.е. исключения бывают из любого правила, но я практик и для меня сейчас двойной форк выглядит, как задротство старперов из академической сферы, которые не способны адаптироваться к реальности. Gentoo без systemd или какой-нибудь Devuan — задротство в чистом виде. Впрочем, расскажешь реальный пример нужности двойного форка — сменю мнение (я гибкий).
В каком-нибудь роутере может быть очень мало памяти/места на флешке, и тогда там может быть не systemd, а что-нибудь более архаичное (и компактное). Вплоть до того, что /sbin/init может оказаться шеловским скриптом, который только и делает, что запускает пару сервисов.
Потом, стоило бы уточнить, что сейчас в мире FreeBSD творится.
Но конечно, если твоя программа не попадет в роутеры и FreeBSD, об этом можно и не беспокоиться.
Здравствуйте, Sheridan, Вы писали:
S>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Sheridan, Вы писали:
S>>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Pzz>Скажи это авторам systemd
Ну в состав systemd входит десятки утилит,
каждая из которых решает довольно небольшую задачу, поэтому претензия к sysytemd непонятна.
Здравствуйте, Zhendos, Вы писали:
Z>Ну в состав systemd входит десятки утилит, Z>каждая из которых решает довольно небольшую задачу, поэтому претензия к sysytemd непонятна.
systemd — это аццкий монолитный кусок г-на. Разбит он при этом на несколько процессов или нет, не имеет значения. Друг от друга независимо они все равно не работают.
С внедрением systemd процесс инициализации системы стал абсолютно непрозрачным, и отлаживать возникающие на этом этапе неисправности стало на два порядка тяжелее.
UNIX way — это когда несколько независимых, полезных по-отдельности, програм можно объединить вместе, и получить из них нечто бОльшее.
Здравствуйте, AlexGin, Вы писали:
AG>И вот тут вот начинается самое интересное: AG>a) Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм, AG>позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
Ты подумай лучше, для начала, кому ты пишешь эти логи. Кто их будет читать? Кто их целевая аудитория?
Потому что если ты пишешь их админу системы, который будет устанавливать и использовать твою программу, то писать надо в терминах, понятных ему, и внутренных подробностей жизни твоей программы не вываливать.
А если ты их пишешь себе, с целью отладки по е-мейл, то во-первых, они должны быть достаточно детальные, чтобы тебе было сразу понятно, чем занималась твоя программа, а во-вторых, в них должно быть удобно ориентироваться. Потому что искать 5 важных строчек по 10-мегабайтному логу может быть нелегко, а если тебе таких дюжину в день набросают, то жизни твоей не позавидуешь.
А потом уже, определившись с целью этого логирования, надо определяться с потребными для ее достижения средствами.
Здравствуйте, Pzz, Вы писали:
Pzz>Здравствуйте, Zhendos, Вы писали:
Z>>Ну в состав systemd входит десятки утилит, Z>>каждая из которых решает довольно небольшую задачу, поэтому претензия к sysytemd непонятна.
Pzz>systemd — это аццкий монолитный кусок г-на. Разбит он при этом на несколько процессов или нет, не имеет значения. Друг от друга независимо они все равно не работают.
Это же отдельные процессы, что сложного запустить каждый по отдельности? Ну нужно будет какой-нибудь
файлы, сокеты и т.д., ничего сложного. И дистрибутивы которые не используют systemd это вполне доказывают,
пакуя некоторые программы из systemd в отдельные пакеты, а заменяя некоторые утилиты на их аналоги.
Pzz>С внедрением systemd процесс инициализации системы стал абсолютно непрозрачным, и отлаживать возникающие на этом этапе неисправности стало на два порядка тяжелее.
По мне так проще. Например раньше часть процесса старта системы не записывалась,
так как система журналирования еще не стартовала, теперь записывается все.
Pzz>UNIX way — это когда несколько независимых, полезных по-отдельности, програм можно объединить вместе, и получить из них нечто бОльшее.
Ну например udev из состава systemd вполне полезна отдельно из systemd,
и используется в системах не основанных на systemd довольно часто.
Здравствуйте, Pzz, Вы писали:
S>>unix way — множество небольших инструментов но каждый хорошо делает своё дело. Не пытайся своим приложением охватить ВСЁ.
Pzz>Скажи это авторам systemd
Нука расскажи мне, да.
Только теперь заметил новое шевеление в данной теме
Думал, что уже здесь обсудили всё — что можно и нельзя.
Pzz>Здравствуйте, AlexGin, Вы писали:
AG>Должно быть несколько категорий записей (например: INFO, DEBUG, WARNING, ERROR, etc...) и механизм, AG>позволяющий путём настроек подсистемы логирования ограничить размер лог-файла — с учётом приоритета данных категорий.
Pzz>Ты подумай лучше, для начала, кому ты пишешь эти логи. Кто их будет читать? Кто их целевая аудитория?
Для начала — разрабы (я и моя команда).
Pzz>Потому что если ты пишешь их админу системы, который будет устанавливать и использовать твою программу, то писать надо в терминах, понятных ему, и внутренных подробностей жизни твоей программы не вываливать.
Да, поиск по тексту — выручит отца русской демократии
Pzz>А если ты их пишешь себе, с целью отладки по е-мейл, то во-первых, они должны быть достаточно детальные,
+100500
Это проработано. Логи вполне себе детализированные.
Но суть применения данного сервиса — скорее локальная автоматизация.
На объекте может и не быть соединения с интернет (скорее интранет),
так что отправка по e-mail — не актуальна.
Pzz>чтобы тебе было сразу понятно, чем занималась твоя программа, а во-вторых, в них должно быть удобно ориентироваться. Потому что искать 5 важных строчек по 10-мегабайтному логу может быть нелегко, а если тебе таких дюжину в день набросают, то жизни твоей не позавидуешь.
Ну 10 мегабайтным он точно не будет.
А в одномегабайтном (это если он ооооочччень сильно разрастётся) — искать уже легче.
Pzz>А потом уже, определившись с целью этого логирования, надо определяться с потребными для ее достижения средствами.
+100500
Посему я и выбрал spdlog — что там можно достаточно просто настраивать уровни логирования.
Здравствуйте, Pzz, Вы писали:
... Pzz>В каком-нибудь роутере может быть очень мало...
Приложение (сервис) пишу НЕ для роутера.
Pzz>Но конечно, если твоя программа не попадет в роутеры и FreeBSD, об этом можно и не беспокоиться.
+100500
Я именно об этом и писал.
