Комментарии 16
юбилейный номер версии?
Сначала они отказались от iptables, а теперь вот sudo. Эх, куда катится этот мир.
Systemd Creator Lands At Microsoft
https://www.phoronix.com/news/Systemd-Creator-Microsoft
Леннарт Поттеринг ушёл из Red Hat и трудоустроился в Microsoft
https://www.opennet.ru/opennews/art.shtml?num=57464
"Компания Microsoft использует systemd в своём дистрибутиве CBL-Mariner, который развивается в качестве универсальной базовой платформы для Linux-окружений, используемых в облачной инфраструктуре, edge-системах и различных сервисах Microsoft..."
https://mastodon.social/@pid_eins/112353324518585654
Как-то даже грустно, что systemd подминает под себя все больше и больше и от гибкой универсальности настройки загрузки не остаётся ничего...
Помню если что надо было изменить - лезешь в init.d скриптики и "гнешь" как хочешь. А теперь что? Куча бинарных (даром что open-source) библиотек завязаных друг на друга...
А чего именно вам не хватает в системд юнитах и прочем тулките ? По моему наоборот всё стало понятнее и лаконичней и ещё быстрей. Хотите колхозить, на запускайте свой баш скрипт из юнита и делайте грязь)
У меня месяц тому назад файлопомойка после перезагрузки "потеряла" зашифрованный RAID-массив. Ребут не помогал - нет раздела и всё тут. Расследование показало что ключи на месте, RAID жив. Просто systemd при старте почему-то не распознаёт ключ, т.е пишет, что ключ неверный. При этом после загрузки если ручками повторить, то всё работает. Вот так и решил проблему: ручками через крон. Если после загрузки раздел не смонтирован, то монтирую скриптом.
Тут проблема в том, что ты уже бессилен как-то починить то, что сломали другие. Ибо бинарник, а не скрипты. Сидел и ждал, пока починят. Сейчас вроде бы раздел снова монтируется при загрузке, но аварийный скрипт я уже на постоянку оставил )
Значит, нарушен порядок загрузки. У меня аналогичная проблема - модуль ngx_auth_ldap при старте зачем-то лезет на LDAP сервер, и если сервер не ответил - убивает весь процесс. При этом на момент старта не факт, что вообще есть сеть, а даже если есть - не факт, что LDAP сервер успел обнюхаться и начать принимать запросы. Пока приходится руками перезапускать nginx после установки сети, но надо будет полностью отказаться от этого недоделка и перейти на ngx_auth_subrequest. Но это не причина ругать systemd, который просто не может знать, что там творится ВНЕ его зоны ответственности. Вам нужно особое поведение - `systemctl edit имяюнита` и пишите любое особое поведение. Например, вставляйте prestart скрипт, который будет проверять, что все необходимые сервисы не просто запущены, а полностью поднялись и реально отвечают на запросы.
не факт, что вообще есть сеть
Именно для этого в юните nginx.service прописано After=network-online.target, вам наверно стоит проверить работоспособность этого
все необходимые сервисы не просто запущены, а полностью поднялись и реально отвечают на запросы.
А для этого есть sd_notify — сервис шлёт READY=1, systemd понимает что сервис поднялся — и только после этого начинает запускать связанные с ним сервисы, без всяких prestart-скриптов
Откуда systemd узнает, что какая-то левая машина где-то там в сети поднялась и работает? Это баг конкретно модуля, что он при старте, без всякой надобности, лезет на LDAP (#1) и полностью крашит старт сервера, если LDAP не ответил (#2). Я поначалу пробовал откладывать старт остальных контейнеров на "после AD DC", но потом просто забил и перезагружаю nginx на проксе через 5 минут по таймеру. Из-за одного тупого модуля задерживать стартап всей системы как-то тупо. Не находите? Дойдут руки, переделаю авторизацию на auth_subrequest и отвяжусь от этой зависимости. И, да, баг в репо модуля на этот счёт висит не первый год. "Всем по…"
А вы в своём предыдущем комментарии ничего не упоминали про «левую машину»
Но даже в таком случае:
приходится руками перезапускать nginx
Restart=always и другие связанные опции
Мне казалось, это очевидно, что LDAP сервер - отдельная машина.
Restart=always - это готовый рецепт катастрофы. Никогда так не делайте.
Мне казалось, это очевидно, что LDAP сервер - отдельная машина.
Ну, ничего не мешает серверу nginx и серверу LDAP находиться на одной машине
Restart=always - это готовый рецепт катастрофы. Никогда так не делайте.
Почему же? Он меня наоборот неоднократно спасал
Ну, ничего не мешает
Только теоретически. Практически, это глупо и небезопасно.
Он меня наоборот неоднократно спасал
Представим вполне себе негипотетическую ситуацию перманентного облома сервиса в определённой ситуации. В определённый момент эта ситуация начинает повторяться с завидной периодичностью. init-демон начинает перезагружать сервис N'дцать раз в минуту, при этом системные извещения о подобной проблеме не продуманы либо просто отказали. В итоге сервис работает 5 секунд, даже что-то делает, и снова валится. А ты об этом узнаёшь через пару недель (в лучшем случае!), когда тебе самому понадобился функционал, вызывающий падение.
N'дцать раз в минуту
Разумеется, рядом с Restart=always я всегда пишу что-то вроде RestartSec=5 чтобы такого не происходило
системные извещения о подобной проблеме не продуманы либо просто отказали
Это не имеет отношения к Restart=always, без извещений катастрофа будет в любом случае. А вот Restart=always наоборот спасает от катастрофы в случае если она лечится этим самым рестартом - вот как в случае с этим вашим nginx
А ты об этом узнаёшь через пару недель
И опять же никакого отношения к Restart=always, без него всё ровно то же самое
Самое классное что они привнесли, это то что теперь не работает suspend если загружен модуль nvidia.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1072722
Пофиксить можно так, надеюсь кому нибудь поможет
/etc/systemd/system/systemd-suspend.service.d/nvidia.conf
[Service] Environment="SYSTEMD_SLEEP_FREEZE_USER_SESSIONS=false"
Вышла стабильная версия systemd 256