вопрос на засыпку по systemd

принципиальное выгораживание systemd как самоцели лишено смысла

Принципиальное обвинение systemd как самоцель лишено смысла.

я просто пояснил тебе, почему твой ответ «systemd формально работает корректно, а ошибка в другом» лишен силы

Хорошо. Давай for the record. В чём, по-твоему, проявляется некорректность работы либо дизайна systemd?

я говорю, это для тебя все сводится к тому, чтобы разбираться с кубиком. а для меня к тому, чтобы «все работало».

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

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

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

А ещё у systemd в коде есть master и slave, его нельзя использовать никого не оскорбляя. Ящитаю Поттеринга стоит засудить за поддержку рабовладения.

А тебе, я вижу, очень хочется понтануться тем, что «запускать команды» и «читать юниты» — это всё, мол, грязная работа

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

Upstart появился в Ubuntu 7.04, который, как не трудно догадаться, был выпущен в апреле 2007 года. Upstart умел распараллеливать загрузку, что давало прирост во времени загрузки пропорционально количеству ядер CPU. Небольшой прирост был также и на одноядерых системах, так как какая-нибудь системная служба могла задуматься при старте, что при последовательной загрузке системных компонентов тормозило загрузку системы, а при параллельной - нет.

И вроде бы Ubuntu - это десктоп, а не серьёзная серверная система. И вроде бы на серверах не критично время запуска... Но Upstart решили внедрять в RHEL 6. А это значит, что Upstart был хорош, и годился не только для десктопов, для которых не требуется супер стабильность.

Вдруг Red Hat и Canonical сильно рассорились. Upstart в последний момент убрали из RHEL 6. То есть, как убрали? Не успели, так как до релиза оставалось всего ничего. Оставили в репозиториях, а по дефолту выключили. Так RHEL остался на SysVinit ещё на один релиз (но загрузка всё равно была распараллелена я не знаю как: в Fedora, openSUSE и Mageia в тот момент как-то научили SysVinit распараллеливать загрузку), а в RHEL 7 сделали Systemd

In Red Hat Enterprise Linux 6, init from the sysvinit package has been replaced with Upstart

https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/6/html...

witch ~ # rpm -qa |grep upstart
upstart-0.6.5-17.el6.x86_64

it's by default

как раз по поводу дизайна.

вопрос на засыпку по systemd (комментарий)

нет, я не могу обвинить мейнтейнеров. они не могли знать, какие именно опции будут в legacy файле и действовали в рамках «простейшей» логики systemd, но эта логика позволяет выстрелить себе в ногу.

Да, стабильный дебиан.

Здесь проблема в другом, имхо. Для большей части пользователей и админов systemd не принёс ничего нового и полезного. Всё уже было в init-скриптах sysv/openrc(upstart я не использовал, поэтому про него говорить не могу). Но как всегда при внедрении чего-то нового вылазят всякие косяки. Плюс необходимость учить новое вместо уже привычного. И некоторые решения в systemd далеко не очевидные. Отсюда и возникает такая ненависть к нему.

Лично я дома так и остался на openrc(десктоп) и sysv(домашний сервак) и переходить не собираюсь, но вот на работе пришлось освоить systemd, так как redhat/debian перешли.

В дебиановском юните именно так.

за исключением того что убивает выхлоп rndc.

У rndc нет выхлопа. Он молча либо возвращает 0, либо 1. Для этого и нужен был в скрипте log_end_msg

а какие альтернативы bind есть? какой ты пользуешься? Интересно.

ты считаешь bind безальтернативным? и по какой такой причине?

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

В чём, по-твоему, проявляется некорректность работы либо дизайна systemd?

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

Да, возможно, systemd действительно прекрасен. Я не настолько плотно его изучил, чтобы составить обоснованное мнение. Но в данный момент на реальных серверах с реальными сервисами от внедрения systemd много проблем, которых не было при использовании sysv. И админу не важно, кто в этом виноват. Поттеринг, мантейнер, криворукий жуниор или ещё кто.

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

В чём, по-твоему, проявляется некорректность работы либо дизайна systemd?

Мне платят не за это

забей, он не может ответить на этот вопрос. совсем. и считает всех говном, мы, видишь ли, не умеем распарсить random true or false || true

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

потому что одно дело большой полноценный скрипт с проверкой, а другое ini файл, где одно из значений может быть скриптом однострочником

Я так понял из треда, что разницы с rhel 6 нет вообще, и никаких доп. проверок на релоад там в скрипте нет. Или всё-таки есть?

А разница с дебианом в том, что в федоре добавлен kill -HUP, который всегда возвращает 0.

Ну как бы да, мэйнтейнеры в федоре ошиблись. В rhel тоже. Ну бывает. Жизнь - боль.

имхо, все в целом это вопрос оценки эффективности инструмента

Ну в данном случае инструменты у тебя - это rhel6 и федора. Systemd, в данном случае, лишь составная часть системы. Безусловно, не идеальная, с пачкой проблем. Но явно лучше, чем тот зоопарк, что был раньше. И в данной конкретной ситуации проблема не в systemd.

И ещё вопрос, ты регулярно говоришь о том, что есть проблема в сохранении совместимости с legacy. Имеется ввиду systemd-sysv и то, что ещё не все сервисы перевели на юниты? Поясни пожалуйста, а то не понятно.

но логирование пока хуже всего остального.

Можно же перенаправлять весь вывод в rsyslog. И ничего не сломается. Или я чего-то не знаю, и таки данные где-то теряют?

Можно, но это как раз пример плохого дизайна. journalctl вносит свою нагрузку при обработки логов. Если мы будем говорить о серверных системах, там потоки логов могут быть очень и очень значительными. Я не знаю, производит ли journalctl какой-то парсинг при таком логировании, но я недавно видел, как journalctl съел пол-ядра cpu при том, что он был в режиме volatile, то есть даже не писал их на диск.

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

Запущена команда и до сих пор работает с PID 31699

/usr/sbin/named -u named -c /etc/named/named.conf -4 -c /etc/named/named.conf

Если для сервиса произвести операцию обновления конфигов, то будет выполнена команда

/bin/sh -c /usr/sbin/rndc reload > /dev/null 2>&1 || /bin/kill -HUP $MAINPID

а на самом деле не будет вопрос на засыпку по systemd (комментарий)

Прямо не будет выполнена команда как есть? Баг в systemd создали? То что команда кривая - другой вопрос

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

Все сервисы, которые я видел, если они пишут значительные объёмы, они либо пишут в файлы самостоятельно, либо опционально пишут в syslog. Не делай им вывод в stdout/stderr, и всё будет как и раньше.

Я не знаю, производит ли journalctl какой-то парсинг при таком логировании, но я недавно видел, как journalctl съел пол-ядра cpu при том

Я так понимаю, что под journalctl ты подразумеваешь journald. Что-то он точно парсит.

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

Но логи системы смотреть в journalctl, имхо, в разы удобнее.

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

Aug 20 03:30:56 dell.inter systemd[1]: Reloaded Berkeley Internet Name Domain (DNS).

Но если в команду добавить третью субкоманду, которая проверяет обновился ли конфиг и возвращать 1 в самой конце, тогда ведь сработает?

ты подразумеваешь journald

ну да, это я подглючиваю уже.

Все сервисы, которые я видел, если они пишут значительные объёмы, они либо пишут в файлы самостоятельно, либо опционально пишут в syslog. Не делай им вывод в stdout/stderr, и всё будет как и раньше.

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

Aug 20 03:30:56 dell.inter systemd[1]: Reloaded Berkeley Internet Name Domain (DNS).

Кстати, опять же, команда как-то сделана странно. Я например понимаю два варианта

1) Просто сделать kill и просить пользователя смотреть не логи systemd, а логи сервиса. Самый простой вариант, хотя рисковано. Можно разве что сервис не очень важный, имеет бекап конфига или работает даже с плохим конфигом

2) Сделать нормальный скрипт валидации конфига и не вызывать kill пока валидация не будет успешной

Они там вгородили «||», а у тебя виноват systemd. Я не знаю что делает первая команда, то логично обычно делать «validate && kill -HUP»

У rndc нет выхлопа. Он молча либо возвращает 0, либо 1.

а у моего есть. совсем не молча он возвращает.

это _уже_ работает. то есть из-за нововведений я должен что-то значительно менять

Имхо, это не большая проблема. В любом случае нужно настраивать что-то и проверять при миграции. Пару строк поменять не добавит хлопот.

а во-вторых, я считаю управление потоками логов в одном месте как раз достоинством.

Полностью поддерживаю. И то, что journald тормозит безбожно на больших объёмах меня крайне удручает. Хочется всё смотреть только в нём. Но пока приходится отдельно.

но их потом и ротировать надо по-особому. согласен?

Ну так же, как и было до systemd, SIGHUP при ротации. Ну или copytruncate, или как там его.

с этой стороны как не крути получается хак, чтобы как-то обойти проблему.

Так точно такой же, как и был.

Т.е. все проблемы логов не решили. Но хуже не сделали.

я на это уже отвечал по треду...

А на это ты мне не ответишь?

перед тем, как делать любые kill -HUP нужно смотреть документацию и рекомендации разработчиков. у бинда есть возможность делать релоад через специального клиента rndc, там kill -HUP ненужен.
валидацию можно засунуть в ExecStartPre, но по хорошему, валидация должна происходить перед попыткой изменить состояние сервиса. и это, мягко говоря «по хорошему», т.к. по плохому — это ГУЛАГ и расстрел.

Пару строк поменять не добавит хлопот.

зависит сколько серверов:)

Т.е. все проблемы логов не решили. Но хуже не сделали.

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

или допустим tomcat писал в syslog, файлы попадали в /var/log..., а теперь мы ему говорим: баста! пиши в файл. он начинает писать совсем не в /var/log... а где там ему пермишшенов хватит.

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

отвечу, когда вернусь

зависит сколько серверов:)

Скрипт/ансибл. М.б. я чего-то не понимаю, но при миграции на новую версию выключение вывода в stdout явно не единственное требуемое действие и на общем фоне, это действие не заметно.

допустим, раньше код веб-приложения отправляет сообщения в syslog

Так journald же забирает только те логи, которые выводятся в stdout/stderr. В syslog можно писать как и раньше ведь?

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

Это да, тоже проблема.

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

Хм. Странно, надо поковырять. Просто буквально несколько недель назад я обновил на своём персональном сервере зону и по невнимательности оставил в файле зоны комментарий, начинающийся с #, а не с ;. Т.е. синтаксическая ошибка. rndc молча отработал, на статус код я не посмотрел и спокойно занялся другими делами. А когда кончилось время кеширования зоны я обнаружил, что мой домен не резолвится. :)

Скрипт/ансибл. ... не единственное требуемое действие и на общем фоне...

В любом случае нужно настраивать что-то и проверять при миграции.

Ну бывает. Жизнь - боль.

Жизнь, безусловно, боль, поэтому не нужно, чтобы IT инфраструктура добавляла ненужный геморой. Ты вот пишешь: тут пустячок подправить, там несколько строк, рецепт для ансибла переписать... пусть логи в двух местах пишутся... и понемногу накапливается как снежный ком. А самое главное ради чего? Цель всех этих изменений какая? Стало от них кому-то лучше? Если нет, то и изменения должны быть сведены к минимуму, потому что каждое из них потенциально несет риск поломки. Отсюда следствие: не надо чинить то, что не ломалось. Не ломалась система логирования? Не нужно ее чинить и т.д. Ты можешь считать сугубо моим личным мнением, но я видел, где IT были поставлены так, что требовалось два человека вместо одного или три вместо двух. И свято в это верю в этот посыл.

Далее поясню это на примере с логами.

но их потом и ротировать надо по-особому. согласен?

Ну так же, как и было до systemd, SIGHUP при ротации. Ну или copytruncate, или как там его.

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

Так journald же забирает только те логи, которые выводятся в stdout/stderr. В syslog можно писать как и раньше ведь?

Вот этого я не понял. journald получает логи «из всех возможных источников», чтобы это не значило. А как на твой взгляд получает сообщения syslog? Просто я знаю, как он работает, а тебя по-моему какая-то своя версия.

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

KISS

Т.е. все проблемы логов не решили. Но хуже не сделали.

Еще раз. Сделали хуже. Дизайн journald не предполагал remote logging. Что-то там сейчас допилили, но вроде курам на смех.

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

Угу. Но не переживай, однажды в старых init-скриптах кончатся рецепты боли и страдания и неочевидная байда-таки вымрет.

Не кончатся. Куча юнитов представляет из себя /etc/init.d/servicename <start|restart|stop>

И далеко не факт, что ини-файлы смогут полностью заменить скрипты и уйти от этого способа запуска.

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

Короткая версия: ну давай конфиги брать из кучи разных мест /etc/legacy1.conf, /etc/default/legacy2.conf... и посмотрим, как быстро ты попадешь себе в ногу...

Длинная версия:

Еще какое-то время назад я бы с тобой согласился. А чем дальше смотрю... ес-но, застабилизируют. я специально пропускаю RHEL7 в надежде, что они застабилизируют к выходу RHEL8. Баги исправят в unit files и т.д. но есть такая вещь как error prone design. Он же дизайн, который позволяет выстрелить себе в ногу. Идея с тем, чтобы сидеть на всех стульях, учитывать все кейсы и обеспечивать совместимость со всем в мире Linux... - хорошая реализация этого всего требует, если не божественного вмешательства, то по крайне мере Линуса самолично (и создал он Git, и был он хорош, и решил Microsoft из этого тоже выгоду извлечь...).

Я буду теперь всевремя приводить в пример named. Вот скажи, что было бы если бы в named.conf можно было бы в каждую директиву скрипт вставлять? Ну там для динамической генерации параметров...

Возьми другой пример, новый линуксовый файрвол с синтаксисом json. Там можно че-то такое такое программировать, но в очень ограниченных приделах.

Теперь возьми какой-нибудь дубовый windows ini файл по типу key=value.

Я считаю либо уж сохранять полноценные скрипты (на любом языке) для полной гибкости и пусть инит делает свое маленькое дело. Либо четко фиксировать конфигурационные опции. А вот этот огород с systemd приводит по сути к тому, что скрипты остаются, но над ними еще два слоя абстракции unit файлов.

ну да, я об этом как раз и написал ^ я только не пойму ради каких благ я это буду ждать.

Странно, надо поковырять.

witch ~ # rndc reload
rndc: 'reload' failed: unexpected end of input
... config edited ...
witch ~ # rndc reload
server reload successful
witch ~ # 

Я так понял из треда, что разницы с rhel 6 нет вообще, и никаких доп. проверок на релоад там в скрипте нет. Или всё-таки есть?

да, разница с RHEL6 только в том, что он не выдает такого сообщения «Reloaded Berkeley Internet Name Domain (DNS).» но если брать пример с nginx (вопрос на засыпку по systemd (комментарий)), где тоже используется kill -HUP, там такая проверка есть. т.е. init скрипт в rhel6 делал нужную проверку, а после миграции на systemd ее потеряли.

Но явно лучше, чем тот зоопарк, что был раньше.

Я честно сказать не знаю, что ты имеешь ввиду. RHEL, Debian и Ubuntu использовали upstart, а скрипты для сервисов были на баше.

есть проблема в сохранении совместимости с legacy. ... Поясни пожалуйста, а то не понятно

вопрос на засыпку по systemd (комментарий)

отсутствия боли и страданий тебе мало?