Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0

  • Tutorial

С Новым Годом, Хабр!


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

Во всём виноват Хабр!

…. Точнее хабражители! А, если ещё точнее, всему виной — предновогодние статьи, в которых два никак не связанных между собой юзера изобрели два почти одинаковых велосипеда. Итак, встречайте моих сегодняшних героев!

Как создавался новогодний Хабрачат в этом году

Скачивается бинарник под нужную платформу из релизов на github. Можно положить его, например, в /usr/bin. Далее пишем простой скрипт, который будет перезапускать сервер, в случае падения.

… (пропущен башизм с бесконечным циклом и прочими sleep-ами)

© оригинал

Безумный дом

В процессе эксплуатации я заметил, что Domoticz иногда падает с ошибкой. Чтобы поднимать его автоматически, напишу watchdog с помощью cron.

… (пропущены башизм, на пару с кронтабом)

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

© оригинал

Что с этим делать и как дальше жить?

Я совершенно не планировал писать статью освещающую самые основы systemd, у меня в планах цикл статей из разряда «systemd для продолжающих», но жизнь, как видно, вносит свои коррективы, в результате пусть моя сегодняшняя, коротенькая статья будет своеобразным прологом к планируемуму циклу. Но так как про написание сервисных юнитов systemd написано 100500 хаутушек, то мы осветим только параметры относящиеся к автоматическому перезапуску сервисов, на конкретных примерах (и на затравку кое-что ещё ;-), в применении к статьям двух уважаемых хабровчан.

Делаем всё по фен-шую

Ну, я надеюсь, вы тут все достаточно технически грамотные, поэтому я сразу приведу готовые, самодокументированные юниты и конфиги, а также команды запуска всего этого безобразия.

«Как создавался Хабрачат в этом году»

Юнит(/etc/systemd/system/ssh-chat.service):

[Unit]
Description=SSH Chat Service
After=network.target network-online.target

[Service]
# Пользователь и группа, с правами которых будет запускаться сервис
User=ssh-chat
Group=ssh-chat
Type=Simple
ExecStart=/usr/local/bin/ssh-chat --admin=/etc/ssh-chat/admins --bind=0.0.0.0:22 --log /var/log/ssh-chat.log --motd=/etc/ssh-chat/motd
# В каких случаях сервис будет автоматически перезагружаться.
# on-failure — в случае выхода с ненулевым кодом возврата.
Restart=on-failure
# Таймаут перед загрузкой сервиса, после падения.
RestartSec=1
# Capablities для сервиса. В данном случае - разрешение сервису
# биндиться на привилегированные порты (< 1000)
AmbientCapablities=CAP_NET_BIND_SERVICE

[Install]
WantedBy=multiuser.target

Конфиг для systemd-sysusers.service(/etc/sysusers.d/ssh-chat.conf):

u ssh-chat - "SSH Chat user" /etc/ssh-chat
# Поля записи:
# u : создаём пользователя
# ssh-chat : username
# - : или UID[:GID] в данном случае автоматически занять свободные UID/GID < 1000
# "SSH Chat user" : Описание, или "-", если не нужно.
# /etc/ssh-chat : Home Directory
# Может быть ещё одно поле -- login shell. По умолчанию /usr/bin/nologin

Инсталляция и запуск:

sudo systemctl restart systemd-sysusers.service && sudo systemctl enable --now ssh-chat

«Безумный дом»

Юнит(/etc/systemd/system/domoticz.service):

[Unit]
Description=Domoticz Daemon
After=network.target

[Service]
User=http
Group=http
# Эта директива позволяет выполнять подготовительные действия перед
# запуском сервиса. Модификатор "+" указывает выполнять их от рута.
ExecStartPre=+/usr/bin/install -d -m 0700 -o http -g http /var/run/domoticz
ExecStart=/opt/domoticz/domoticz -www 8080 -pidfile /var/run/domoticz/domoticz.pid
PIDFile=/var/run/domoticz/domoticz.pid
WorkingDirectory=/opt/domoticz
# Всё то же самое, что и в случае "хабрачата", только таймаут 5 секунд.
RestartSec=5
Restart=on-failure

[Install]
WantedBy=multi-user.target

Инсталляция и запуск:

sudo systemctl enable --now domoticz

Что дальше?

Возможности systemd, кратко освещённые в этой статье, а так-же многие другие, более подробно будут разобраны в следующих статьях цикла. Триггеры, поддержка бинарных форматов, «прозрачные»(transient) юниты, встроенная контейнеризация and more, more... Но нетерпеливые могут уже «вот прям щаз» заняться чтением одной из лучших документаций в мире линукс. Маны которые можно почитать по сегодняшней теме:

man systemd.unit
man systemd.service
man systemd.exec
man systemctl
man sysusers.d
man systemd-sysusers

И на закуску маленький секрет. Один из моих любимых манов: man systemd.directives - путеводитель по всем директивам конфигурации которые могут встретиться вам в процессе изучения systemd.

Ещё раз С новым Годом, Хабр! И используйте правильные инструменты!

PS: Добавил ссылку на ман по systemd.exec. Как-то я про него малость забыл.

PPS: Добавил ссылки на ресурсы.

Список статей серии

  1. Почему хабражители предпочитают велосипеды, вместо готовых решений? Или о systemd, part 0

  2. Systemd для продолжающих. Part 1 — Запуск юнитов по временным событиям

  3. Systemd для продолжающих. Part 2 — Триггеры на различные события

Ресурсы

  • systemd.io — Статьи по внутренней кухне systemd. Частенько упоминается в манах.

  • systemd @ freedesktop.org — Основная страница с манами, документацией, видео, блогами и прочими ссылками на ресурсы.

  • @ru_systemd — Русскоязычный чат в Telegram. У нас тепло и лампово.

Only registered users can participate in poll. Log in, please.

Продолжать?

  • 89.9%True581
  • 10.1%False65

Similar posts

Ads
AdBlock has stolen the banner, but banners are not teeth — they will be back

More

Comments 245

    +6

    Интересная тема. Необходимость заполнить конфиги sgstemd возникает крайне редко, чтобы изучать всё тонкости. Как правило обзожусь копипастой с беглым пролитыванием документации. Поэтому узнать как правильно нужно сделать и почему у очень хорошая задумка

      0
      Ну на самом деле, если не закапываться, то обычному пользователю достаточно почитать маны перечисленные выше, плюс маны по journad/journalctl и маны по таймерам, если хочется функциональности и удобства побольше чем в cron. Дальше уже идут всякие интересные, но не так сильно распространённые, штуковины.
        +6

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


        С другой стороны, systemd есть не везде по дефолту, если говорить о мире виртуалок, контейнеров и прочих облак.

          +3
          Пользователю полезно держать в голове набор правил вида — «если тебе нужно это, то используй вот то», часто люди начинают городить велосипеды на костылях просто потому что не знают что есть готовое решение, которое просто нужно использовать.
          Зная что для твоей задачи лучше всего использовать, например, systemd, уже легко сможешь найти всю необходимую информацию о том как его использовать, в сети или в манах все легко находится.
            +2

            А маны по другому устроены:


            • это делает это
            • это делает то
              :(
              +1
              Это да, но вот лично для меня обычно главная проблема это понять каким инструментом лучше всего решается задача, вопрос как ее решать уже чаще всего намного проще, тем более по распространенным инструментам обычно в сети много инструкций в которых все подробно описано.
                +2
                так именно этими знаниями (знанием что лучше использовать) и ценится IT специалист (developer, system/software engineer), а не способностью печатать буковки на клавиатуре — это и обезьяна умеет
            0
            С другой стороны, systemd есть не везде по дефолту, если говорить о мире виртуалок, контейнеров и прочих облак.

            Недостоверно. На уровне операционки — он есть уже везде. Там, где нет — это маргиналы, которые скорее всего знают, как жить без него.
            Единственное, где боль — это «засунуть системди в контейнер», но это не нужно, потому что там сама система оркестрации (тот же кубернетес) берет на себя функции системди (запуск, хелсчеки, управление ресурсами и пр)

              +1
              У systemd есть своя собственная система контейнеризации systemd-nspawn, в которой запихать в контейнеры systemd можно, а местами даже нужно. Так что это не принципиальная невозможность, а особенности конкретной реализации контейнеров. Но для контейнеров приложений, где 1 контейнер == 1 приложение (докер/кубер и и же с ними) systemd внутрь запихивать и не нужно.
                0
                У systemd есть своя собственная система контейнеризации systemd-nspawn, в которой запихать в контейнеры systemd можно, а местами даже нужно

                спасибо, я в курсе. А еще можно не играть с контейнеризацией nspawn, а попросту использовать те механизмы изоляции, которые предоставляет сам systemd — там и изоляция неймспейсов, и cgroups, и лимиты на ресурсы, и возможно сделать chroot в различных формах — вот контейнер и получился.

                  0
                  Ну это-то да.
                0

                В LXC systemd присутствует.

                  +3

                  никакой боли если ты используешь нормальные контейнеры а не docker

                0
                А если закапываться, то есть конкретные вопросы на решение которых просто положили, из расчета кому надо и кто понимает, найдет решение, а остальным хватит 640kB
                Собственно про journald выше упомянутый, который ну нифига не является достаточно производительным решением by design

                Хотя в основном решение неплохое. ))
                  0
                  Если нечто слишком много льёт в логи, это нечто есть смысл вынести в отдельный journald namespace.
                    0
                    На него отдельный процесс journald создастся?
                      0
                      Да. Почитайте ман systemd-journald.service, раздел JOURNAL NAMESPACES Там на каждый неймспейс создаётся свой экземпляр сервиса из шаблонов. Это можно использовать ещё и для безопасности, если, вдруг, какой сервис пишет чувствительные данные.
                      0
                      Почитал в доках, похоже что то в этом направлении делают.
                      Но пока не вижу решения, вариант выделите явный источник логов в отдельный канал предварительным описанием конфигов явно не решение. Пока костыль, возможно даже поможет, если не дешевле мимо него обработать.
                        0

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

                      +2
                      journald достаточно производительный by design, у него даже rate limit, например, в общем-то аналогичен rsyslog'у (1000msg/30sec vs 20000msg/10min соответственно). Да, он однопоточный, но можно запустить отдельный поток, тут про это уже написали.

                      А ещё я бы серьёзно поразмыслил над вопросом реальной необходимости логирования в таких количествах, что озвученная проблема производительности так остро стоит.
                        +1
                        Я просто оставлю это здесь, пока не ушел
                        www.researchgate.net/publication/228694459_Rsyslog_going_up_from_40K_messages_per_second_to_250K
                        тут просто тупо решают проблему увеличения производительности с 40k в секунду до 250 к в секунду

                        до 40к в проде не приходилось, 20к было, оно в эластик штатно укладывалось
                        гдет пара терабайт в день по объему выходило.
                        На машину это около 500 — 4000 в сообщений в секунду. Без особой оптимизации.
                        Только ключевое условие, весь софт писал напрямую в локалхост по udp на rsyslog.
                        journald критично не справлялся.
                        По стоимости это выходило < гита оперативы на машину, и 1 — 4% cpu, ну машины толстые были.
                        Все мысли на тему реальной необходимости в практике спускаются свыше, и далее в результате консенсуса цена — возможность реализуются на практике.
                          0
                          Вероятно, идея была в том, что в таком количестве данные надо класть в какую-нибудь БД, а не в сислог. Там и производительность может быть выше, и возможностей хитрых поисковых запросов (надо же потом эти данные как-то смотреть) больше.
                            0
                            Ну не зря-ж придумали всякий ELK… Хотя нет. На момент написания статьи, ещё не придумали.
                  +16
                  Потрясающе. Подобного плана статьи одни из самых ценных, среди всех.

                  Т.е наглядно.
                  Проблема
                  Решение
                  Немного комментариев почему, зачем и нахрена.

                  И ничего лишнего!

                  Super! Respect!
                    +3
                    Этой статьи-бы не было, если-бы не велосипедостроение имени хабра. ;-)
                      +2
                      Немного комментариев почему, зачем и нахрена.

                      И где оные можно увидеть?
                      В данном конкретном случае я вижу только «а вот вам конфиг».
                        0
                        в манах и их разжуют в последующих статьях. Возможно.
                          0
                          Так комменты в коде в конфигах.
                      +3
                      Ну наконец-то, дождались)
                      Единственное что, про конфиг было бы приятно немного подробнее. Или же сделай первую статью в цикле как раз про конфиги, потому как эта единая строка пока выглядит как-то… неясно.
                      Спасибо!
                        0
                        Про конфиг sysusers.d?
                          +2

                          Давно практикую services & timers, но вот это первый раз вижу и сходу не понял… Пари старте системе убежлается, что юзкр есть?

                            0
                            Да. При старте systemd-sysusers.service пробегается по каталогам с конфигами, вычитывает их, а дальше действует подобно ансиблу. Если пользователь есть — ничего не происходит. Если пользователя нет, то пользователь создаётся согласно описанию.
                            IDEMPOTENCE
                            Note that systemd-sysusers will do nothing if the specified users or groups already exist or the users are members of specified groups, so normally there is no reason to override sysusers.d vendor configuration, except to block certain users or groups from being created.

                            Вы можете сами посмотреть содержимое директории /usr/lib/sysusers.d там есть примеры конфигов поставленных вместе с пакетами и из поставки systemd.
                        +2

                        ExecStartPre=+/usr/bin/install -d -m 0700 -o http -g http /var/run/domoticz


                        А почему не через systemd-tmpfiles?

                          0

                          Автор ещё тем велосипедописателем оказался!

                            +1
                            Конкретно этот юнит не мой… Кстати, хорошая мысль сходить в AUR и отправить ишью автору пакета.
                            +1
                            Я думал об этом, но это пришлось-бы расписывать его синтаксис. О systemd-tmpfiles будет отдельно и подробно.
                              +8

                              Всё ещё проще:


                              [Service]
                              …
                              RuntimeDirectory=domoticz
                              RuntimeDirectoryMode=0700
                              …

                              И, согласно FHS 3.0, следует использовать /run вместо /var/run

                                +4
                                Точно! Кстати подали хорошую идею. Подготавливать рантайм и контекст для сервиса можно разными способами. Но как я уже говорил, конкретно этот юнит жертва копипасты. В оригинале там ещё и deprecated директива была.
                              0
                              Ну а что, как минимум велосипеды полезней)
                                +5
                                Велосипеды полезней там, где без них никак. Там-же где есть штуки которые более лучше, проще и надёжнее, лучше использовать именно их!
                                  –3

                                  Эти факторы субъективны. Если 30 лет писал на баше init скрипты и т. п., то systemd или supervisord подходы выглядят непонятно (какой шелл будет выполнять ExecStart? Что будет в енв переменных? В чем конкретно разница типов сервисов? ), непредсказуемо (какая последовательность вызовов? Как мониторится состояние процессов и мониторится ли) и, как следствие, потенциально ненадежно и/или оперативно не поддерживаемой в случае инцидента.


                                  А профит для глубокого изучения кроме моды какой-то непонятен

                                    +5
                                    Самый главный профит — система делает за вас процентов 90 тех вещей которые приходилось решать кодом на баш.
                                    Логику запуска/перезапуска/остановки/релоада конфигов. Логгирование, изоляцию логов, отправку логов на удалённые хосты. Проверку статуса сервисов, ограничение ресурсов (память, проц, сеть, доступ к FS), зависимости запуска сервисов и так далее и тому подобное. Причём если вам не нужен какой-либо функционал, вы вольны просто им не пользоваться. Собственно в systemd есть ровно три обязательных компонента. Сам systemd, journald и udevd. Всё остальное не является обязательным и заменяемым. Например в большинстве десктопных дистрибутивов используется NetworkManager вместо штатного systemd-networkd.
                                      –3
                                      Вообще-то ничего там не приходилось решать. Все было решено задолго до systemd. Тоже, правда, не без неочевидных и, порой, странных выкрутасов. Однако этот код на баш и сегодня продолжает исправно работать. И вообще-то мне кажется, людей которые понимают как именно он работает больше, чем из лагеря топящего за системд
                                    +1
                                    велосипеды — это опыт, который намного лучше закрепляется, нежели использования готовых решений.
                                      0
                                      Главное что-бы этот опыт не становился практикой.
                                        0

                                        Многие лучшие практики и мировой известности продукты начинались как чей-то велосипед )

                                  –4
                                  А что делать, если я systemd не использую? В исходном варианте было универсальное решение, в вашем — оно прибито к systemd.
                                    +6

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

                                      +1
                                      На серверах в проде?
                                        0
                                        Ага. FreeBSD и Devuan. На тестовых и рабочих машинах — Gentoo
                                          +10
                                          Ну значит вы точно сможете обеспечить запуск сервиса у себя, да ещё и так как вам надо. Эта-же статья для тех у кого systemd, включая и тех у кого малина с Raspebby PI OS, или как там сейчас raspbian правильно зовётся. Просто когда система обеспечивает контроль над сервисом, снимая с вас энное количество головняка, глупо этим не воспользоваться.
                                            –6

                                            И забирает этот контроль у вас) Особенно весело, если в документации указаны традиционные или экзотические способы запуска, а кто-то переписал на systemd и нигде это не упомянуто...

                                            +1

                                            И что, в FreeBSD, Devuan и Gentoo одинаковое универсальное решение? Не, конечно, в принципе возможно поставлять шелл-скрипт, который будет дублировать функциональность инит-системы, учитывая специфику разных ОС и дистрибутивов, и который все равно придётся дергать из rc-скриптов, но какой в этом смысл?

                                              –1
                                              Вполне себе, sysvinit скрипты едят они все.
                                                +4

                                                А зачем в той же FreeBSD или Gentoo пихать голые sysvinit-скрипты, дублирующие функциональность инит-систем адской копипастой?


                                                Когда пользовался FreeBSD и Gentoo, всегда такие портяночные скрипты переписывал под родную для системы инфраструктуру, и из 100 строк получалось 10.

                                                  0
                                                  Это если в универсальность. Если мы идём на Gentoo/Devuan — мы идём на OpenRC.
                                                    +4

                                                    Эта универсальность скорее зло. Сколько раз такое было, когда качаешь какую-нибудь проприетарщину, которая разворачивается в /opt с sysvinit-скриптом, и потом мучительно дебажишь копипасту с race condition, найденную тем индусом на каком-нибудь stackoverflow, после чего все равно переписываешь на тот же openrc или systemd unit.


                                                    Написание rc-скрипта или юнита — это достаточно несложная задача, чтобы с ней нельзя было справиться за 10 минут, имея в качестве примера что угодно вменяемое. А если там что-то архисложное и замороченное (как в том же MySQL до восьмерки было), это скорее говорит о качестве продукта :)

                                                      –1

                                                      Как правило достаточно совсем уж дичь добавить в /etc/rc.local или в cron при reboot (и в crontab нужного пользователя)
                                                      Будет запускаться после запуска всего и будто в консоли запустили руками...

                                                        +1

                                                        Не люблю такое (хоть и делаю иногда), как-то неаккуратненько :)

                                              +5
                                              Ох, ну и мину вы подкладываете работодателю, если по найму работаете.
                                                –1
                                                В чём мина? FreeBSD вполне себе используется ещё, Devuan — на основе Дебиана собран, у меня половина реп от Дебиана подключена, ручками обычно только стартовые скрипты приходится делать и задачи в крон.
                                                  +7
                                                  Вкратце, меньше людей заходят работать с таким стеком при наличии выбора и примерно равных других условиях. Экзотика.
                                                    0

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

                                            +3

                                            Можно вопрос для пополнения личной статистики? А по каким объективным техническим причинам было решено использовать НЕ systemd?

                                              –1
                                              Бинарные логи. Я не понимаю, почему для более-менее читабельных после разрушения ФС логов я должен городить велосипед и подключать ещё один классический логгер, который мне уже сделает логи, вместо того, чтобы изначально писать их в текстовом виде.
                                                +1
                                                Я могу быстро получать из логов нужную мне информацию… Но внезапно могу обрабатыватть её и классическими sed/grep/awk/что-угодно. Видать опять что-то делаю не так. Или вот вы мне из классических логов сможете достать вывод dmesg позапрошлой загрузки?
                                                  0
                                                  А теперь бинарный журнал journald теряет 4Кб в начале и где-то ещё в середине нули лезут. Как это читать?
                                                    +3

                                                    В случае небинарных журналов никаких гарантий того, что они целостны — нет. Поэтому — да, формат проще и в теории их восстановить проще, но если там условный аудит — я бы ему не доверял априори.

                                                      0
                                                      ЭЭЭ… мухи с котлетами не путайте. Формат файла и целостность перпендикулярны, вы можете делать бинарную вставку с хэшем, можете просто делать текстовую вставку с кэшем и префиксом, можете просто держать отдельный файл с таблицей
                                                      1 строка — хэш
                                                      2 строка — хэш от первой и от второй
                                                      и тд

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

                                                      Противоречие в примере вашем вижу я :)
                                                      Если это настолько важный и нужный комп, что побитый лог (бинарный или нет — не суть) — проблема, значит, верно одно из:


                                                      1. Лог неправильно хранится. Его нужно пулять вовне (rsyslog и аналоги)
                                                      2. Дисковая подсистема не обеспечивает целостность инфы в нештатных ситуациях — всё ли хорошо с железом? Не побьётся ли в следующий раз инфа более важная, чем лог?
                                                        0
                                                        Бывает так, что есть 15Вт на всё и максимум 2G канал связи (а то и его нет). А дисковая система и сейчас без рейда ничего не обеспечивает, SMR диску достаточно очень неудачно отключить питание и прощай транслятор (SSD кстати тоже, промышленные не случайно имеют батарею конденсаторов).
                                                          0
                                                          хм, если у нас нет никакого канала связи, то что делает этот комп? :)

                                                          … ладно, окей, он рулит некими условными заслонками на трубопроводе гдето в мерзлоте, и всё управление по RS485 :) питание по нему же (да, я изверг)
                                                          … но в таких условиях явно надо хотя бы raid 1 и тупо аккумулятор.
                                                          но в описанных ОЧЕНЬ СПЕЦИАЛЬНЫХ условиях явно будет трудиться ОЧЕНЬ СПЕЦИАЛЬНЫЙ линукс, там не то что systemd, там много чего не будет, на 15 ваттах то…
                                                      –3

                                                      Ну, например, в centos по дефолту journald не хранит даже предыдущий dmesg, после ребута его логи начинаются с момента загрузки.


                                                      А вот как мне в journald разделить логирование разных сервисов по разным журналам? =) Никак, да? Жаааль. Значит снова без syslog не обойтись. Вот ведь!

                                                        0
                                                        Ну, например, в centos по дефолту journald не хранит даже предыдущий dmesg, после ребута его логи начинаются с момента загрузки.

                                                        sudo mkdir /var/log/journal
                                                        sudo chown root:systemd-journal /var/log/journal
                                                        sudo chmod 2755 /var/log/journal

                                                        «И ваши волосы станут мягкими и шелковистыми». ©
                                                        А вот как мне в journald разделить логирование разных сервисов по разным журналам? =) Никак, да? Жаааль. Значит снова без syslog не обойтись. Вот ведь!

                                                        «Читайте маны, они рулез!» © ;-)
                                                          0
                                                          «И ваши волосы станут мягкими и шелковистыми».

                                                          Ваши шутки очень остроумны и смешны. Спасибо, я знаю, как это настроить. Обратите внимание на слово "по дефолту". Извиняюсь за слэнг, это означает — "по умолчанию".


                                                          «Читайте маны, они рулез!» ;-)

                                                          В оригинале было "читайте доки", кмк. Ну раз уж с копирайтами. :)
                                                          Да, namespace'ы есть, но в той же доке вы найдете ограничения и описание их реализации — через маунт неймспейсы, что в свою очередь велосипедизм. Протокол syslog имеет вполне простой и понятный механизм разделения facility/priority без велосипедов.
                                                          Мы же от них вроде как хотели избавиться?

                                                            +1
                                                            Протокол syslog имеет вполне простой и понятный механизм разделения facility/priority без велосипедов.

                                                            Только этого множества (facility/priority) зачастую недостаточно, учитывая количество разнородных источников логов внутри типичной системы....

                                                              0
                                                              Ваши шутки очень остроумны и смешны. Спасибо, я знаю, как это настроить. Обратите внимание на слово «по дефолту». Извиняюсь за слэнг, это означает — «по умолчанию».

                                                              Все вопросы к ментейнерам вашего дистрибутива, не? Systemd тут ровно никаким боком. Это ментейнеры centos не озаботились включением постоянного хранилища для логов.
                                                              Протокол syslog имеет вполне простой и понятный механизм разделения facility/priority без велосипедов.

                                                              journald аналогично имеет простой и понятный механизм разделения facility/priority. Если мне какой-то юнит выдал ошибку, я сразу, одной командой могу посмотреть логи связанные с этой ошибкой. Безо всяких велосипедов. И да. Неймспейсы это не про разделение facility/priority.
                                                                –1
                                                                Все вопросы к ментейнерам вашего дистрибутива, не? Systemd тут ровно никаким боком.

                                                                Конечно. Так изначальный ваш посыл был про посмотреть позапрошлые dmesg. Очевидно, что при небольшой настройке это легко получить и без journald с обычным ®syslog. А если journald нужно донастраивать специально, то тогда 1:1. Только про это речь.


                                                                journald аналогично имеет простой и понятный механизм разделения facility/priority.

                                                                И какой? Если Namespace'ы не про это, как вы сами только что сказали.
                                                                Facility как раз позволяет легко и просто решить задачу разделения логов по (группам) сервисов (источников). Уверен, вы это знаете. Именно это было задачей, на которую вы сами же тыкали меня в маны парой ответов выше.

                                                                  +1
                                                                  И какой? Если Namespace'ы не про это, как вы сами только что сказали.

                                                                  Да, неймспейсы не умеют разделять перенаправление отдельных syslog facilities по отдельным журналам, признаю. Но в вашем изначальном комменте, собственно про facilities ничего не было.
                                                                  А вот как мне в journald разделить логирование разных сервисов по разным журналам?

                                                                  И это я вам сказал как — раскидав по разным неймспейсам. Это хорошо и для производительности и для безопасности. Про syslog facilities это вы уже в процессе вбросили. Но при этом посмотреть отдельные логи с фильтром по facility / priority / time / log namespace любым другим признакам вы можете одной командой, быстро, удобно и без напрягов. Плюс к этому вы можете вообще не писать логи на диск / в память, а сразу перенаправлять их куда вам удобно (syslog / kmsg / tty / wall), да хоть во всё сразу. При этом для каждого неймспейса будут свои правила, в отдельных конфигах.
                                                                  А если journald нужно донастраивать специально, то тогда 1:1. Только про это речь.

                                                                  Не нужно, ибо официальный ман journald.conf говорит нам:
                                                                  Storage=
                                                                  Controls where to store journal data. One of «volatile», «persistent», «auto» and «none». If «volatile», journal log data will be stored only in memory, i.e. below the /run/log/journal hierarchy (which is created if needed).
                                                                  If «persistent», data will be stored preferably on disk, i.e. below the /var/log/journal hierarchy (which is created if needed), with a fallback to
                                                                  /run/log/journal (which is created if needed), during early boot and if the disk is not writable. «auto» behaves like «persistent» if the /var/log/journal directory exists, and «volatile» otherwise (the existence of the directory controls the storage mode). «none» turns off all storage, all log data received will be dropped (but forwarding to other targets, such as the console, the kernel log buffer, or a syslog socket will still work). Defaults to «auto» in the default journal namespace, and «persistent» in all others.

                                                                  Note that when this option is changed to «volatile», existing persistent data is not removed. In the other direction, journalctl(1) with the --flush option may be used to move volatile data to persistent storage.

                                                                  Вот даже теперь и вручную не нужно создавать директории в /var/log — оно само. Главное изменить Storage=persistent или auto, даже лучше auto, что-б не потерять сообщения на ранних этапах загрузки.
                                                                    –1
                                                                    Но в вашем изначальном комменте, собственно про facilities ничего не было.

                                                                    Не было. А почему там должно было быть про них? Речь же шла про (не)возможности journald, а не syslog.


                                                                    И это я вам сказал как — раскидав по разным неймспейсам. Это хорошо и для производительности и для безопасности. Про syslog facilities это вы уже в процессе вбросили.

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


                                                                    Но при этом посмотреть отдельные логи с фильтром ...

                                                                    Я тронут, но вы напрасно расписываете мне возможности jd. Я, безусловно, не знаю их все, но уже и далеко не на уровне первой страницы мана. Вынесите это в статью — будет намного полезней, имхо.


                                                                    Моя изначальная цель разделение логов — это не "удобно посмотреть одной командой". У меня на хосте много сервисов, часть из них пишут в логи на порядки больше других. Соответственно, разделение их по журналам требуется для решения нескольких задач: разные дисковые хранилища, разные настройки ротирования(!), и разные параметры компрессии (где нужно), и разная детализация(!!!) и форматы представления.
                                                                    Плюшки journald далеко не бесплатны, и удобство фильтрации вносит оверхед 2 (два) порядка по объему логов, занимаемых на диске, по сравнению с текстовыми. Это не для красоты речи — это результат испытания на двухнедельном архиве боевых сервисов.
                                                                    По человечески, без хаков, решить такую задачу на jd — близко к невозможному.

                                                                      0
                                                                      Я тронут, но вы напрасно расписываете мне возможности jd. Я, безусловно, не знаю их все, но уже и далеко не на уровне первой страницы мана. Вынесите это в статью — будет намного полезней, имхо.

                                                                      Всё будет! журналирование несомненно в планах.
                                                                      По человечески, без хаков, решить такую задачу на jd — близко к невозможному.

                                                                      Ну совсем уж сложные задачи надо форвардить соответствующим инструментам. Стёк ELK и что там у нас сейчас есть, из стильно-модно-молодёжного.
                                                                        –1
                                                                        Стёк ELK и что там у нас сейчас есть, из стильно-модно-молодёжного.

                                                                        Вот мы и вернулись к моему изначальному посылу =) Понимаете, что для этой задачи не нужно никакого молодёжного стека, кроме элементарной возможности разделения журналов. Всё остальное давно уже есть. Другое дело, что архитектура jd скорее всего не позволит это реализовать в том виде, как оно сделано для rsyslog. Это не плохо и не хорошо, просто инструменты отличаются. Поэтому, да, jd позволяет одной строкой вывести предыдущий dmesg или там логи с момента загрузки — неплохо, удобно. Но есть и минусы, и есть простые вещи, которые были, а теперь их нет и их не хватает для реальных задач.


                                                                        Согласитесь, честно будет писать не только плюсах.

                                                                          0

                                                                          Я честно не понимаю Вас.


                                                                          Согласитесь, честно будет писать не только плюсах.

                                                                          несомненно. Кто-то спорит? Рассказывайте о минусах. Еще раз — systemd — модульная система. Нет никакой беды в том, чтобы замещать его компоненты какими-то другими внешними компонентами, если предложение от systemd Вас не устраивает. Что не так?
                                                                          В случае сложного кейса вроде Вашего вариантов несколько:


                                                                          1. использовать "чистый" journald, смирившись с его ограничениями (например, закидать каталог под логи дополнительным местом с отдельного физ накопителя)
                                                                          2. перестроить архитектуру систему — например, отказавшись от локального хранения логов и перенеся его в некую централизованную систему. Как минимум ЦЕНОЙ РЕСУРСОВ получите интересные бонусы вроде корреляций между событиями в разных системах и на разных узлах + та же самая ротация индивидуальная для каждой системы/подсистемы. Еще раз повторюсь, что локальные логи — это днищенско, потому что в случае, например, потери виртуалки (сломалась окончательно), Вы ее теряете вместе с логами. К тому же кто гарантирует целостность логов? НИКТО. А вот внешняя система хоть какие-то гарантии дает (она работает как append-only хранилище на самом деле, но тут уж как настроишь, и вопрос с транспортом стоит особо остро).
                                                                          3. использовать связку journald + rsyslog/syslog-ng…
                                                                            может можно еще что-то.
                                                                            0

                                                                            А я не понимаю вас =) Я привел контрпример "просмотра предыдущго dmesg", достаточно простой кейс, когда journald (конкретно jd, а не вообще systemd, который в целом мне нравится) или не удобен или вообще не может решить проблему самостоятельно, без привлечения старого sysloga.
                                                                            Но, похоже, наши протоколы несовместимы. Наверное, я до сих пор текстовый и ламповый, и одной командой меня не посмотреть =) Так что замнем для ясности, видимо.

                                                                              0
                                                                              Я подозреваю что проблема непонимания кроется в том, что у syslog и jd разные идеологии работы с логами.
                                                        +4

                                                        Никто не только не заставляет пользоваться исключительно journald, но даже и вообще писать его бинарные логи на диск. Неправильно воспринимать сабж как замену для какой-нибудь
                                                        классической системы типа rsyslog. Его задача — собирать всеми возможными способами вывод разнообразного софта в единое полотно. А что дальше с этим потоком логов творить — ваше дело. Можно, например, буквально за 10 секунд сделать так, что journald будет хранить логи только в оперативной памяти + форвардить их в классический rsyslog/syslog-ng/ваша_привычная_система. И пусть она пишет в текстовые файлы по любой желаемой логике, пересылает по сети на единый сервер, сливает в /dev/null — всё, что захотите.
                                                        Использовать "классические" системы без такой прослойки в мире современного софта, часто пишущего свои логи тупо в stdout, ОЧЕНЬ неудобно. Как минимум, нужно много костылей по передаче fd этих stdout от каждого запущенного скрипта в одну из многочисленных "классических" систем логирования. Journald же встроен в init систему и позволяет проворачивать такие вещи элементарным образом.


                                                        Так что конкретно это и близко не техническая причина, просто вы не разобрались до конца в целевой нише journald.

                                                          0
                                                          А оставить у systemd только задачи старта/остановки/контроля запуска (т.е. классические задачи системы init) я малой кровью могу?
                                                            0
                                                            Надо будет как-нить в виртуалке оставить только сам systemd / journald / udevd Только зачем так урезать функционал? Самому на баше его реализовывать?
                                                              0
                                                              А вообще выкинуть journald, чтобы вместо него изначально был, к примеру, syslog-ng?
                                                                +1
                                                                Можете, только тогда вы потеряете логгирование, но как вам уже выше сказали, journald вполне себе может гнать поток напрямую в syslog.
                                                                  –3
                                                                  Рецепт в студию ))
                                                                  верней 2 рецепта
                                                                  1) redhat like os
                                                                  2) debian like os
                                                                  Нужно отключить вообще journald
                                                                  все логи, ядро и прочее должны идти в rsyslog или syslog-ng
                                                                  идти они должны напрямую, не через journald.
                                                                    +2

                                                                    А в чём разница (с точки зрения результата) между "логи идут напрямую в rsyslog" и "journald пересылает все логи в rsyslog"? Без стёба, я во всём этом действительно слабо разбираюсь и хочу понять суть спора.

                                                                      +1

                                                                      по сути ни в чем, кроме того, что наши коллеги убедительно хотят выкинуть из системы те компоненты, которые считают лишними )))

                                                                        0
                                                                        Embedded. Чем меньше лишнего — тем лучше. =)
                                                                        0
                                                                        На больших объемах логов journald просто не справляется, вырезать его в принципе нельзя. В итого приходится локально пинать логи по udp с приложения на rsyslog(ng-syslog).
                                                                          +1
                                                                          вырезать его в принципе нельзя

                                                                          Доказательства будут? Или это очередное. Кхм. Неподтвержденное утверждение?

                                                                            –2
                                                                            github.com/systemd/systemd
                                                                            тут код ))
                                                                            вырезать путем создания форка и переписывания в принципе можно, а вот путем конфигурирования нет.

                                                                            Еще какие доказательства нужны? Не хочется (можется) по коду, ну загуглите сей вопрос.
                                                                              +1
                                                                              Еще какие доказательства нужны?

                                                                              Ну наверное доказательства того, что если не выпилить journald, перенаправляя поток в syslog (ибо, как вы утверждаете, «journald не справляется с нагрузкой», кстати неплохо-бы и этому утверждению привести доказательства) логи так и будут «захлёбываться».
                                                              0
                                                              Плюс он может форвардить/принимать логи на удалённые хосты, собствеными силами, отдельным systemd-journal-remote.service.
                                                                +1
                                                                Я бы это, если честно, применял только в случае необходимости сливания логов в пределах локалхоста через сокеты. Подозреваю что оно именно для данной задачи и делалось, больно уж сыро для реальной ненадёжной сети всё. Для консолидации с кучи машин на отдельный сервер всё-таки лучше что-то специализированное расчехлить.
                                                                  +1
                                                                  Нет, это делалось именно с рассчётом на сеть.
                                                                  DESCRIPTION
                                                                  systemd-journal-remote is a command to receive serialized journal events and store them to journal files. Input streams are in the Journal Export Format[1], i.e. like the output from journalctl
                                                                  --output=export. For transport over the network, this serialized stream is usually carried over an
                                                                  HTTPS connection.

                                                                  Вы-ж не боитесь, когда у вас классический syslog данные по сети гоняет? ;-)
                                                                    +1
                                                                    Вкратце:
                                                                    — Да, я (естественно) читал мануал
                                                                    — Да я это пробовал
                                                                    — Нет, у меня не сложилось впечатление о том, что это пригодно для прода — слишком много нюансов всплывает в реальной эксплуатации. Я, если честно, ни одного места с systemd-journal-remote в эксплуатации не знаю.
                                                                      0
                                                                      А какие нюансы, можно вкратце?
                                                                        +2
                                                                        Вкратце оно в принципе не рабочее.
                                                                        Вообще. За исключением вариантов потестить что оно работает на статистической погрешности.
                                                                          +1
                                                                          Ясно, спасибо, то-есть если нужно гнать на удалённыйхост, лучше использовать форвард в syslog.
                                                                  +1

                                                                  Вот этой функцией я не стал бы пользоваться. То ли ее не оттестировали, то от не доработали, но работает так себе.

                                                                    0
                                                                    Ну давайте так, систему легирования systemd по факту убил, вернее усложнил и сделал частично неработоспособной.
                                                                    Варианты как посмотреть что то роли не играют.
                                                                    Рассказы про валидацию логов, ну тоже если честно.
                                                                    По крону, есть кейсы где интересней, но в общем то на то и вышло.
                                                                    Есть варианты сильно лучше чем написание программ для запуска (баш портянок)
                                                                    есть хуже, появились новые возможности (но сильно опоздали, показатель просто тупо запуск через докер(podman))
                                                                    Претензии конкретные, замена функционала по логированию на софт не способный это делать, и не возможность простыми способами использовать альтернативы.
                                                                      0
                                                                      Ну давайте так, систему легирования systemd по факту убил, вернее усложнил и сделал частично неработоспособной.

                                                                      Я только отчасти с этим согласен. Потому что докер системы логирования точно так же «убил». Все сейчас серят в stdout/stderr, а дальше это уже задача инфраструктурный платформы не умереть обрабатывая это ) и передавать логи в отдельное хранилище.


                                                                      Претензии конкретные, замена функционала по логированию на софт не способный это делать, и не возможность простыми способами использовать альтернативы.

                                                                      Я не пробовал выкорчевывать journald, но есть гипотеза, что если сделать слушающий сокет /dev/log через тот же rsyslog/syslog-ng, то вы сможете использовать «лучшее» из обоих миров. Systemd модульный и никто не заставляет использовать те его компоненты, которые Вам не нравятся. Например, как выше уже говорили — сеть зачастую настраивают не через systemd-network, а через networkmanager или ifup (кажется, пакет iproute2). То же с управлением ntp — не нравится systemd-timesyncd? Ставь chrony


                                                                      но сильно опоздали, показатель просто тупо запуск через докер(podman))

                                                                      Здесь я тоже скорее соглашусь, что докер «взлетел» существенно быстрее и, скажем так, навык его использования есть сильно у бОльшего количества людей, чем навык использования системди. Касательно того, что системди опоздал — вряд ли на самом деле. Потому что все эти «ядерные» штуки для контейнеризации появились в мейнстриме не так уж давно. И поэтому попросту сделать это раньше возможности не было.

                                                                  –4
                                                                  Отсюда вопрос, наверно я отстал от жизни, запускаю я через systemd, по старой памяти оно гадит в stdout — stderr
                                                                  как мне это в rsyslog минуя journald отправить?
                                                                  Ну могу тупо в udp перенаправить, просто средствами linux и с определенной версии systemd, далее читать на сокете. Но это костыли, я просто так могу решить ограничения этой системы, есть другие костыли. Но вы мне говорите что есть универсальная система, но блин она не МОЖЕТ прокачать мой объем логов, и дальше?

                                                                  Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум(с systemd не помню как тогда было), вы просто не смотрели их документацию.
                                                                  К journald у меня конкретная претензия, мне приходится ее тупо выпиливать и заменять на rsyslog, syslog-ng, различные шипперы логов типа filebeat и тд (их ну дофига, тупо читают файл и пинают по tcp(udp))

                                                                  Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца, жду минуту (что по cpu и памяти смотреть не хочу, раньше было страшно, но на машине 32 гита оперативы, и в общем не смертельно)
                                                                  еще раз, жду минуту, shift-gg (в переводе, покажи последнее)
                                                                  в терминале (даже фантастическом) меньше 300 строк, утилита вместо того чтоб тупо прочитать (с бинарных данных, с ИНДЕКСАЦИЕЙ) последние 300 строк, посмотреть сколько у меня терминал показывает и вывести, тупо ЧИТАЕТ ВСЕ ЛОГИ ПОСЛЕДОВАТЕЛЬНО.

                                                                  Я не разобрался… ))

                                                                    0
                                                                    Что вы запускаете? journalctl? -n количество_строк не пробовали, например?
                                                                      –1
                                                                      Я знаю как использовать journalctl, в примере выше сценарий явно расписан

                                                                      это просто тупо логика, и она ну нифига не реализована, и посему если нужно чтоб journalctl использовала начальная линия поддержки, его приходится обкладывать альянсами или скриптами

                                                                      Претензия по моему конкретно расписана, вы скажете что это не правда?
                                                                        +2
                                                                        Лично у меня из примера сложилось впечатление о том, что вы просто journalctl вызвали и дальше руками до конца полотна мотаете.
                                                                      +2
                                                                      Классические системы, как вы сказали, все эти проблемы решили еще 10 лет назад как минимум

                                                                      Проблемы софта, пишущего в stdout/stderr не решили, только костыли с педиректом вывода полуручными методами
                                                                      Ну тупой кейс, забил в консоли journalctl, нажал вниз до конца

                                                                      Ну так именно что не разобрались, судя по написанному. Потому что и вывод можно фильтровать по разному и искать по временным рамкам и индексирование, учитываемое при чтении имеется. И, конечно же, это всё не работает от слова совсем ежели вы самолично просите вывалить вам ВСЕ логи, которые имеются в принципе.
                                                                        0
                                                                        shift — gg это вниз до конца, управление идет с терминала, проматывать логи нафиг не надо, хочу посмотреть последнее.

                                                                        вывалить все логи — и управление с терминала управляющей последовательностью команд, по моему несколько разные вещи.
                                                                          +2
                                                                          Когда вы вбиваете journalctl в консоль, то читаются все логи и передаются в pager (по умолчанию это less), а последний уже и обрабатывает ваше GG, переходя в конец текстового полотна.
                                                                          Где в этом процессе вы увидели хоть какое-то управление или фильтрацию логов в самом journalctl? Самое натуральное «прочитай и вывали мне всё, что есть, а я промотаю руками до конца», только обмазанное less.
                                                                            –1
                                                                            Я это прекрасно понимаю, еслиб journalctl мне просто стал бы гнать весь лог в консоль, или плюнул 10 строк + сообщение «тут только начало, пни добавь параметр и покажу все»
                                                                            Вопроса бы не было.
                                                                              +1
                                                                              journalctl --no-pager

                                                                              А ещё есть такая команда:
                                                                              journalctl --pager-end

                                                                              И такая:
                                                                              journalctl --reverse
                                                                                –1
                                                                                Ох… ну я знаю параметры…
                                                                                Суть в другом, тут уже отписали, что да, народ пинает ныне все в докере, и логи в stdout, stderr и в докер втыкают в параметры неблокируемый вывод, и дальше в F(syslog) неожиданно оно так умеет
                                                                                и дальше рулят, и не от удобства и крутости journald, а от того что оно не выполняет свои функции…
                                                                                  +3
                                                                                  Я это прекрасно понимаю, еслиб journalctl мне просто стал бы гнать весь лог в консоль
                                                                                  journalctl --no-pager
                                                                                  Ох… ну я знаю параметры…

                                                                                  Нихалеры не понятно. Зачем вы спрашиваете, если знаете. Это уже начинает напоминать откровенный то-ли троллинг, то-ли хейтинг…
                                                                                    +2

                                                                                    Так делают просто потому что есть старый привычный инструмент, а journald — новый и нужно привыкать.

                                                                          +1
                                                                          journalctl —since=tomorrow

                                                                          Можно и конкретные дату/время указать.

                                                                            0

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

                                                                              +1
                                                                              Ой, конечно же yesterday :-)
                                                                  0

                                                                  Пишу свой велосипед хаба умного дома. Сейчас делает всё, что нужно мне. Когда задался вопросом запуска нужных демонов начал разбираться с systemd. После этого выкинул нафиг все остальные системы инициализации, тем более systemd используется у меня и в Gentoo и в Ubuntu или Raspbian на малинке. Даже крон не нужен. И всё работает отлично. Я уж не говорю о том, что запустить систему с графикой в Gentoo без systemd гораздо сложнее.

                                                                    +9
                                                                    По моему скромному мнению, systemd это одна из лучших вещей которые случались с linux за последние лет 15.
                                                                      0
                                                                      Двоякое мнение, с одной стороны стало проще, с другой стороны особых изменений это не принесло. Скорее всякие куберы и номады движутся в более правильном направлении, и systemd их пытается догонять, но он уже проиграл. Максимум что он вытеснил другие системы инициализации но чисто политическими механизмами.
                                                                        0
                                                                        с другой стороны особых изменений это не принесло

                                                                        Ну, что здрасьте. Начать с того, что не везде есть и могут быть куберы/номады и они тоже не святым духом работают (читай поверх тех же виртуалок с линуксом и системди), и кончая тем, что sys v init надо было сжечь. Вы никогда не сталкивались с его ограничениями? По тому, что Вы говорите — очевидно нет. А системди это все изящно решает и упрощает operations

                                                                          –2
                                                                          Вообще за 20 лет работы сталкивался, но ограничения все эти спокойно обходятся. Про здрастьте, в новых убунтах в сообщение дня вбито, ставьте куб, локальный, не парьтесь мозг. Там народ видно не в курсе, или просто забил.
                                                                            –3
                                                                            Я вообще в последнее время сильно часто наблюдаю тупо compose файл для докера, это однозначно systemd заслуга?
                                                                              +2

                                                                              Поясните — как композ файл взаимосвязан с системди?
                                                                              Начну с того, что компоуз не замена системди НИ РАЗУ. Компоуз — это способ промоделировать запуск нескольких микросервисов на машине разработчика. Отсюда все его ограничения. Попробуйте связать компоуз и реальный мир. Компоуз и порядок монтирования файловых систем или порядок запуска сервисов. В компоуз нет таймеров/крона
                                                                              И пр. пр. пр. пр.

                                                                                0
                                                                                Никак, разработчику не впился systemd
                                                                                ему нужен механизм запуска его творения на целевой системе, ну и init систему
                                                                                он рассматривает как такой механизм, но к сожалению мир не совершенен, и поэтому ему сильно проще передать через формат компоуз файла информацию, чем курить nnn… количество мэн документации по systemd
                                                                                В итого, субъект становится штукой которой интересуются полторы калеки которые работают прям на железе, но к сожалению он для них так же проблемен, ибо не выполняет заявленных функций.

                                                                                И да, я и есть те полторы калеки, монтирование файловых систем, запуск задач по таймеру и тд я решал еще 15 лет назад, связываю компоуз и реальный мир я каждый день, неожиданно мне за это платят, и не зп, мне клиенты платят. И пр. пр. пр.
                                                                                  +1

                                                                                  Разработчик, которому не впился системди — это не разработчик, а калека. Точно так же, как почему-то разработчику внезапно необходимо понимать как работают базы данных. Если, конечно, мы под разработчиком не понимаем веб-кодера-макаку, но что тогда плакать о том, как у нас в целом софт плохо работает и требует для работы беспрецедентные мощности? Люди на Луну летали на существенно меньших мощностях, чем есть в современном ПеКа.

                                                                                    –1
                                                                                    Ну опрос проведите ))
                                                                                    90% разработчиков про systemd краем уха, и то только название ))
                                                                                    мой прогноз, на выборке из бэкендеров ))
                                                                                      +2
                                                                                      Тут вон разрабы не могут рассказать за отличия TCP от UDP. О чём вы вообще!
                                                                                        –1
                                                                                        От вас я только жду рассказ как в RedHat — like и debian — like системах вырезать journald.
                                                                                        А разработчики за себя и сами думаю могут сказать ))
                                                                                        За сим откланиваюсь, ответы читать буду завтра, карма знаете ли ))
                                                                                        Сложно поддерживать несколько нитей разговора с разными людьми имея ограничения. Но можем пообщаться где нибудь на другой платформе, где политические, религиозные, технические и прочие воззрения не могут сказываться на возможности выражения мыслей. ))
                                                                                  0

                                                                                  Частично замена. Restart опции там есть, что позволяет не писать кучи service файлов, только для docker-compose run service cronjob {ну и таймер к каждому). В последнем композе что и для джоб сделали, но доки на момент релиза не было ещё

                                                                                +5
                                                                                Почему-то напомнило

                                                                                Если без шуток, то сейчас бы всякие оркестраторы с системами инициализации в одну кучу валить и сравнивать. Или на локалхосте кубер для банального запуска софта использовать.

                                                                                  –1
                                                                                  Ну а без шуток, к тому все и идет. ))
                                                                                    0

                                                                                    У меня больше вопрос что использовать оптимально на одиночных дев-стейдж-прод серверах для запуска своего серверного прикладного софта. Вариантов куча, агитируют вокруг в основном за k8s или, вот, systemd. Но стойкое ощущение, что половину разрабов надо будет в админов переобучать, пока спасём я башем и кроном и docker-compose, но всё-же кое-что переписал на systemd, чтоб нагрузку джобов балансировать по времени. Работает, но не скажу, что понравилось…

                                                                            0
                                                                            Эмм, а чего сложного в генте без системд с графикой? rc-update add xdm default и готово. Работает с Amd/NVidia/Intel/Mali/Openchrome/Voodoo, с прочей экзотикой не проверял, сорри. Или разговор о графике в консоли (хотя её имхо похоронили вместе с fbsplash)?
                                                                              +1
                                                                              Не знаю. У меня на 5.9.x ядре прекрасно играет mplayer в tty. Похоронили скролл в tty, это да :-(.
                                                                                0
                                                                                Я про украшательства tty в формате «сча картинку в бэкграунд зафигачим и область для вывода текста выделим». За убийство скрола я очень сильно обижен, т.к. 5.10.2
                                                                                  0

                                                                                  А есть ссылка под рукой про похороны? Думал глюк обновления какого-то, да всё руки не доходили разобраться…

                                                                            –1

                                                                            Спасибо пиши плз

                                                                              +2
                                                                              $ man systemd.directives | wc -l
                                                                              7710

                                                                              Тут возникает вопрос — а как я вообще должен догадаться, что из этого использовать для своего приложения?


                                                                              Вот у вас, например, в первом конфиге есть строка


                                                                              AmbientCapablities=CAP_NET_BIND_SERVICE

                                                                              В исходной версии с баш-скриптом ничего про выдачу прав нет — там просто биндинг на порт, и понеслась. Я systemd пользовался на уровне "скопипастить готовый конфиг", и никогда бы в жизни не догадался, что мне такое надо что-то вот такое хитрое добавить, чтобы заработало.


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

                                                                                +1
                                                                                $ man systemd.directives | wc -l
                                                                                7710


                                                                                Вы некорректно посчитали. Директив самого systemd там меньше. Как минимум в два раза, если не в три. А кроме директив systemd там присутсвуют ещё и директивы udev, связанные с systemd параметры ядра, параметры crypttab и fstab, параметры командной строки различных утилит, системные переменные, ну и сами ссылки на маны, в которых всё это описано. Короче это такое содержание «Энциклопедии юных сурков» © ;-) Так что, на самом деле не всё так страшно. Этот справочник хорош когда вы увидели в каком-нибудь юните неизвестный параметр, хотите о нём почитать, то можете выгрепать ман в котором он описан.
                                                                                man systemd.directives|egrep -A1 'UnknownParameter'


                                                                                Тут возникает вопрос — а как я вообще должен догадаться, что из этого использовать для своего приложения?


                                                                                Три основных мана для написания собственных юнитов, по крайней мере юнитов типа *.service, это systemd.unit — директивы общие для всех юнитов; systemd.service — директивы специфичные для юнитов типа *.service и наконец systemd.exec — директивы выставления окружения юнитов — environment, рабочие каталоги, права, лимиты на использование ресурсов (mem / cpu / net etc) и в том числе директивы связанные с Capabilities — это такие мандаты в ядре линукс, которы позволяют процессу запущеному из под непривилегированного пользователя пользоваться некоторыми возможностями рута. В данном случае возможность биндиться к любому порту меньше 1000. Описание этой подсистемы, как и список всех «Cap-s» можно посмотреть в
                                                                                man 7 capabilities
                                                                                  –2
                                                                                  Разрешите докопаться?

                                                                                  Для чего вы egrep вместо fgrep написали?
                                                                                    0
                                                                                    Привычка. Очень часто приходилось писать
                                                                                    grep -E
                                                                                    , потом, однажды, мне это надоело. ;-)
                                                                                      0
                                                                                      Я про то, что ключ -E тут не нужен, а ключ -F — не помешает.
                                                                                        0
                                                                                        Так я и говорю, просто привычка. Что-б не париться, не вспоминать, а не egrep-ли совместимое я сейчас написал.
                                                                                0

                                                                                Oxyd, а если демон — питоновский скрипт, что будет считаться его "зависанием"? При ошибке он просто выкидывает исключение и прекращает работу. Systemd это может отловить? А то сейчас приходится через cron делать restart каждые 10 минут (в гарантированной паузе между заданиями), вне зависимости, есть ошибка или нет.

                                                                                  +2
                                                                                  Он завершает работу с каким кодом завершения? Если ему организовать ошибку, что-бы он упал, а потом сказать
                                                                                  echo $?
                                                                                  какую цифру напишет? Если !=0 то можете не волноваться, systemd, по умолчанию, любой ненулевой код возврата считает за fail сервиса.
                                                                                    +2

                                                                                    Можно сделать ход конём и использовать в своём питоновском скрипте sd_notify. Это нечто watchdog-like, созданное для отправки в systemd keepalive сообщений и оповещений об изменении состояния сервиса через специальный сокет. Можно отслеживать и обрабатывать не только падения с ошибками, но и, например, зависание сервиса.

                                                                                    +2

                                                                                    По поводу автоматического перезапуска упавшего сервиса есть нюанс: по умолчанию systemd позволяет не более DefaultStartLimitBurst(=5) перезапусков за интервал, равный DefaultStartLimitIntervalSec(=10s). После чего юнит уходит в failed state и больше не перезапускается вообще. Так что может быть нужным либо StartLimitIntervalSec/StartLimitBurst поправить, либо интервал межу рестартами увеличить. Или сервис может упасть навсегда после пяти неудачных попыток рестарта.

                                                                                      0

                                                                                      Этот пост напомнил про развитие автоматизации запуска сервисов на моем предприятии.


                                                                                      1. (до меня) баш скрипты и крон
                                                                                      2. (меня взяли на работу) переписываю все на systemd
                                                                                      3. (я ухожу в отпуск на год, зато у нас появился DevOps студент) все переписывается на Ansible, еле еле уговорил не прикручивать Кубернетис (это для запуска 2.5 сайтов на Joomla и одного rest-api на Django то)
                                                                                        0
                                                                                        (я ухожу в отпуск на год, зато у нас появился DevOps студент) все переписывается на Ansible

                                                                                        Я надеюсь, за год, он ничего серьёзно не сломал?
                                                                                        +1
                                                                                        Привет от Оникс (но это не я) 8-)
                                                                                        Системд это хорошо, но ещё лучше указывать дистр где это всё работает. Например, в центосе 7 несколько устаревшая версия, и я не могу по человечески ограничить логгирование демона. 8-(
                                                                                          +1
                                                                                          О! Здорово! Оникс тоже передавай привет и поздравления! :-) Ну с 245.* версии systemd точно должно работать! Сейчас уже 247.*-я версия. Вот аккурат перед Новым Годом, с обновами прилетела.
                                                                                          +3

                                                                                          Ни разу не линуксоид, но ещё в бородатых десятых для себя подымал оракл под центосью и считал что раз умные дяди в ораклях считают что через системд правильнее, то и мне нех выеживаться.
                                                                                          И вообще, первый шаг в решении любой проблемы (не только научной, или инженерной) должен быть анализ имеющихся решении.
                                                                                          К сожалению, дилетантский подход "программист не читатель, а писатель" получил большое распространение с массовым входом вайтишников.
                                                                                          И как раз такие дилетанты в основном и пройдут мимо этой статьи :)

                                                                                            –6

                                                                                            Тут есть и другой фактор — системд монструозен, что-то из того, что сделал для своего сорта пошло не так и вообще не знаешь куда копать. Его даже просто руками не запустить…

                                                                                              0

                                                                                              Если не хочется лезть в systemd, можно поставить supervisord

                                                                                                –1

                                                                                                Плюс супервизора, кстати — разделение настроек запуска и работы системных и своих приложений...

                                                                                                  +1

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

                                                                                                    –2

                                                                                                    Разработчик может принести его всегда, через CD, например.


                                                                                                    Но вот для локализации проблем, когда "ничего не работает" очень полезно иметь быструю и простую возможность посмотреть статусы сервисов ОС и своих отдельно. Да и автодополнение когда раздельно тоже удобно.

                                                                                                +2

                                                                                                Линукс тоже монструозен. Все. Аргумент слит.

                                                                                              –4

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

                                                                                                +4
                                                                                                Но блин. systemd-же удобен! Вне зависимости от того кто ты… И да. Программисты тоже занимаются зарабатыванием денег. Причём поболее некоторых менеджеров.
                                                                                                  0

                                                                                                  Сколько лет у вас ушло, чтобы понять что он удобен?

                                                                                                    +2

                                                                                                    Меньше года. На самом деле — пять минут.

                                                                                                      +4
                                                                                                      Сразу как прочитал первый ман и на основе стандартных написал свой первый юнит.
                                                                                                        –2

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

                                                                                                          +2
                                                                                                          Блин, ну там маны-же подробные, легкочитаемые, а уж всякие статьи про внуреннюю кухню, на systemd.io вообще иногда читаются как увлекательная книга.
                                                                                                            0

                                                                                                            Возможно для практикующих администраторов или системных программистов и так.

                                                                                                              +1

                                                                                                              Да, документация у systemd прямо эталонно хороша. Её, на мой взгляд, можно смело ставить в пример того, как нужно маны писать.

                                                                                                                +3

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

                                                                                                                  +2

                                                                                                                  Да, арчвики выручает… ещё и на русском к тому же )

                                                                                                                    0
                                                                                                                    Арчвики да, согласен, хороша, спору нет!
                                                                                                                      0

                                                                                                                      Я из-за арчвики с убунты на арч в итоге перешёл. Доволен.

                                                                                                                        0
                                                                                                                        Ну я выбрал компромиссный вариант — манджару. Тоже доволен. Как десктопная ОС для айтишника, как по мне, она оптимальна.
                                                                                                        –4

                                                                                                        Всё это я нагуглил вчера, ещё до того как Вы выложили статью. Теперь, пожалуйста, приведите обратный пример. Как убить service в указанное время (и чтобы он больше не поднялся). Способы с systemd.time и Conflicts я и сам нашёл, но хочется обойтись без велосипедов systemd.

                                                                                                          +2
                                                                                                          Если хотите без systemd(ну кроме использования sytemctl), до добавьте в crontab
                                                                                                          systemctl stop servicename
                                                                                                          Если я правильно понял то что вы хотите. Но я-б создал таймер, всё-таки.
                                                                                                            –3

                                                                                                            Нет, я имел ввиду решение с systemd timer и Conflicts — это и есть велосипед, имхо. А сейчас Вы предлагаете cron, хотя статья, о том как уйти от cron.


                                                                                                            systemctl stop servicename

                                                                                                            После выполнения сервис сможет подняться после перезагрузки. Придётся ещё disable добавлять. А если сервис не нужен то ещё удалить его и сделать daemon-reload. А если их много, например, 10, 100 и более, то это вряд ли будет удобным решением.

                                                                                                              +2
                                                                                                              Ну а как вы думаете оно должно быть реализовано? В *.service юнитах нет времени жизни юнита. В systemd разная функциональность разнесена по разным типам юнитов. Если вам нужно что-бы что-то сработало по времени, используйте systemd.timer. Если, например, нужно что-бы нечто срабатывало, на событие в файловой системе, используйте systemd.path. Он, правда, не такой продвинутый как incron или inotifywait/inotifywatch но тем не менее.
                                                                                                                0

                                                                                                                Думаю, что логично, что управление процессами подразумевает не только их запуск, но и другие действия, в том числе остановку. Посмотрите, какое решение с помощью systemd предлагают для схожей задачи:
                                                                                                                Starting and stopping systemd services with OnCalendar for a period of time, every day

                                                                                                                И на сколько, по Вашему, оно элегантно? Повторюсь, если требуется запустить процессов больше, чем 1, то количество юнитов и таймеров возрастает пропорционально.

                                                                                                                  0
                                                                                                                  Повторюсь, если требуется запустить процессов больше, чем 1, то количество юнитов и таймеров возрастает пропорционально.

                                                                                                                  Сделайте специальный юнит, который остановит все нужные по списку. В результате у вас будет один таймер. А иначе задача «хочу остановить определённые сервисы» не решается, список всё равно придётся где-то хранить.
                                                                                                                  Как вариант — systemd targets.

                                                                                                                    0

                                                                                                                    А как при таком подходе сообщить оснвному юниту сервиса, что это плановая остановка, а не авария, и не нужно его срочно перезапускать?

                                                                                                                      0

                                                                                                                      А разве при остановке через systemctl stop или Conflicts=… сервис будет перезапускаться?

                                                                                                                        0

                                                                                                                        Увы, нет. Даже если стоит Restart=Always. Причём это исключительное поведение, не укладывающееся в общую документированную логику — это исключение нужно помнить наизусть и знать какие ещё есть способы остановки сервиса эквивалентные systemctl stop (в документации они даже не упомянуты).

                                                                                                                          0

                                                                                                                          Но почему "увы"? Это самое логичное поведение (та самая "плановая остановка"). И оно, вообще-то, документировано.

                                                                                                                            0

                                                                                                                            Я вообще не понимаю проблему
                                                                                                                            mayorovp все правильно говорите
                                                                                                                            VolCh так что не так? если ты делаешь docker stop для сервиса с restart=always, то он заново рестартовать не будет. 1:1 в противостоянии докера и системди

                                                                                                                              –1

                                                                                                                              Защита от случайного стопа. И логике противоречит, если я явно указал "всегда", а есть исключения.


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

                                                                                                                                0
                                                                                                                                И логике противоречит, если я явно указал "всегда", а есть исключения.

                                                                                                                                не противоречит )

                                                                                                                                  0

                                                                                                                                  Ну да, только нужно сделать попраку логики на философию...

                                                                                                                        0
                                                                                                                        Можно группировать сервисы в таргеты и запускать/останавливать именно их. Мало того, можно делать иерархию из таргетов, таймеров, сервисов и прочих юнитов.
                                                                                                                          0

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

                                                                                                                            0

                                                                                                                            Учитывая, что все-таки как правило одна виртуалка — одна роль, то такие гиперсложные системы вряд ли нужны.
                                                                                                                            То есть остаются, наверное, железки, либо очень многокомпонентные сервисы — вроде того же гитлаба, но насколько я помню, большинство не парится и его запускает тупо через omnibus, или более того — docker.

                                                                                                                              0

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

                                                                                                                              +1
                                                                                                                              Да собственно стандартная организация target-ов в поставке systemd уже простейший пример. И, например, systemctl resque, под капотом аналогичен команде systemctl isolate resque.target — То-есть остановка всего в текущем таргете и запуск всего что прописано в зависимостях к resque.
                                                                                                                      +1
                                                                                                                      После выполнения сервис сможет подняться после перезагрузки. Придётся ещё disable добавлять. А если сервис не нужен то ещё удалить его и сделать daemon-reload. А если их много, например, 10, 100 и более, то это вряд ли будет удобным решением.

                                                                                                                      Это прикол такой? Вы сейчас достаточно мощный исполнительный механизм пытаетесь использовать как оркестратор. Как бы совершенно разные задачи и уровни абстракции. Со своей задачей системди разбирается на ура, Ваши аргументы против неубедительны.
                                                                                                                      А то что Вы хотите — это Scm плавно мигрирующий в оркестрацию.
                                                                                                                      Либо костылить теми средствами, которые есть в системди (вариант с таймером и внутри systemctl disable юнит — не самый плохой, кстати)

                                                                                                                        +1
                                                                                                                        Это прикол такой? Вы сейчас достаточно мощный исполнительный механизм пытаетесь использовать как оркестратор. Как бы совершенно разные задачи и уровни абстракции. Со своей задачей системди разбирается на ура, Ваши аргументы против неубедительны.

                                                                                                                        Пользоваться ещё не начал, но как раз в поисках решения. Сейчас всё работает на 2-х "bash-велосипедах" по крону. Собственно, вроде бы статья о том, как от велосипедов избавиться, но видимо не всё можно решить с systemd.
                                                                                                                        Даже если использовать timer, то либо на каждый процесс создавать отдельный таймер, либо внутри таймера вызывать тот-же bash-скрипт с логикой управления процессами. Возвращаемся к велосипедам.
                                                                                                                        Задача на самом деле тривиальная: клиент оплачивает услугу — запускается серверный процесс. После окончания оплаты процесс завершается.

                                                                                                                          +1

                                                                                                                          Вам не systemd нужен, а serverless (lambda, functions)
                                                                                                                          Ну, и аналогичный функционал можно намутить на системди с триггером запуска по сокету, например, — есть опция создания transient юнитов или шаблонизированных юнитов
                                                                                                                          Примерно так https://m.habr.com/ru/post/161011/


                                                                                                                          Ну, и в конечном счете не проблема задать максимальное время выполнения юнита через тайм-ауты (но это лучше для one shot подходит) или, скажем, RuntimeMaxSec

                                                                                                                            +1

                                                                                                                            Спасибо, немного успел ознакомиться. Под задачу мне больше подходят шаблоны, попробую с ними разобраться.

                                                                                                                    +2

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

                                                                                                                      –1
                                                                                                                      bash скрипт, или python или Perl или go или ...? ))
                                                                                                                      тоесть любая init система ))
                                                                                                                      Тут все деферамбы systemd сводятся к тому что оно уменьшило необходимость написания этих скриптов ( программ) и заменило эти программки на конфиг а претензии к тому, что там где раньше сидела программа которая нормально работала, под общую лавочку завезли что то, что зачастую не работает (ну или работает в n… количестве кейсов, но вариант не использовать systemd при этих кэйсах сделали весьма сложным)
                                                                                                                      Ну а ответ на ваш вопрос, любая. Они до systemd решали эти вопросы. И сейчас решают.
                                                                                                                        +2
                                                                                                                        bash скрипт, или python или Perl или go или ...? ))
                                                                                                                        тоесть любая init система ))

                                                                                                                        Это не init-системы, а вагоны костылей разной степени запутанности. Они нативно и без велосипедов нередко и запустить/остановить то нужный софт не могут.
                                                                                                                          –1
                                                                                                                          Обсуждаемо, задача любой синит системы ( в минимуме) сводится к запустить, остановить, отследить статус. Потом к этому добавили формирование окружения и тд, потом логику.
                                                                                                                          Вот то что вы называете костылями оно просто добавляет логику. Либо эта логика заложена в синит сиcтеме, ну а вы спрашивали какая синит система способна. Отвечаю, любая, потому что есть по сути Тьюринг полное приложение в виде скрипта, или это сразу описанной в программе.