Devuan Excalibur 6

Да, разрабатывать новое - плохо. Надо сидеть на старом.

Что новое-то? Было бы там что-то новое…

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

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

А теперь, когда есть по-факту только одна система инициализации, разрабам системд тем более нет необходимости заморачиваться какими-то стандартами.

следовало обдумать и предложить решение, которое позволило бы интегрировать dnsmasq без его привязки его к systemd

Скажи, друже, ты нормальный вообще? Ты на каждую клиентскую машину в сети предлагаешь затащить комбайн с поддержкой DNS+DHCP+TFTP+BOOTP+RA вместо того, чтобы иметь маленький легковесный DNS-резольвер?

принять некий стандарт, описывающий взаимодействие абстрактного менеджера сети

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

НАМ НЕ НРАВИТСЯ SYSTEMD
@
ЭТО БЛОАТВАРЬ
@
ВТАЩИМ ГИГАСЕРВЕР ВМЕСТО RESOLVED
@
ВОТ ТЕПЕРЬ ХОРОШО

Л - логика.

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

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

~# ps -p $(pidof systemd-resolved) -o pid,ppid,cmd,%mem,%cpu,rss,vsz
    PID    PPID CMD                         %MEM %CPU   RSS    VSZ
    180       1 /usr/lib/systemd/systemd-re  0.0  0.0 13176  21452

У меня в сетке около 70 хостов, dnsmasq (debian 12) раздаёт им dhcp, а также кеширует dns внешний, служит внутренним dns для этих 70 хостов, ну там ещё по мелочам - перенаправляет запросы .ru на специальные сервера и т.п.

# ps -p $(pidof dnsmasq) -o pid,ppid,cmd,%mem,%cpu,rss,vsz
    PID    PPID CMD                         %MEM %CPU   RSS    VSZ
2244191       1 /usr/sbin/dnsmasq -x /run/d  0.0  0.1  2332  14328

Без комментариев…

Без комментариев…

Вау, 10 мегабайт в 2025 году. Большая разница, конечно. Зато процессора ест меньше.

Это плата за дополнительные DoT и mDNS/LLMNR.

Зачем переписывать, если уже есть? А если попробовали и не смогли сделать лучше, зачем пихать своё вместо уже готового, лучшего? А если уже впихнули, почему бы не сделать так чтобы лучший мог бы хотя бы работать без проблем? И так почти со всем этим системд…

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

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

К другим утилитам (coreutils, util-linux, busybox) таких претензий почему-то нет. Ну и это зависит от того как ты пакеты делаешь – делай разными пакетами и никакой проблемы не будет.

На десктопе я его уже не трогаю (раньше сносил), но в качестве сервера для внутренней сети dnsmasq незаменим.

Здорово, но причем здесь resolved, который выступает клиентской, а не серверной, частью?

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

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

• . – глобальный
• work.com – рабоий
• home.lab – домашний

У меня на ляптопе два VPN (в нормальном смысле) – на работу и домой. Чтобы это все нормально работало, кто-то должен уметь различать на какие DNS-серверы посылать запросы – эту задачу resolved и решает.

Ну может быть где-то ещё одну строчку поменять в конфиге по какой-то причине.

Ну так ее и поменять. В рхел resolved нужно поставить, заменить resolv.conf,э на симлинк, и все работает. В арче так же. Проблемы нет.

К другим утилитам (coreutils, util-linux, busybox) таких претензий почему-то нет.

Потому, что бузибох - это под конкретную нишу, а обновление util-linux никак не затрагивает coreutils. А с systemd именно, что coreutils с util-linux (образно) в одну кучу свлили и приправили ethtool-ом какми-нибудь. У разработчиков systemd Л - логика.

Проблемы нет.

Очень сомневаюсь, при случае как-нибудь проверю. Чтобы системдэ и без проблем? Такого ещё не бывало.

Но вообще речь не про Арч и не про Редхат, речь про Дебиан.

У меня на ляптопе два VPN (в нормальном смысле) – на работу и домой. Чтобы это все нормально работало, кто-то должен уметь различать на какие DNS-серверы посылать запросы – эту задачу resolved и решает.

Разумеется dnsmasq это может делать, откуда вообще идея, что он это не умеет? Что там вообще сложного?

причем здесь resolved, который выступает клиентской, а не серверной, частью?

резолвед это сервер разумеется, он вообще-то на запросы клиентов отвечает

Типичный пример - DE, у которого поменялся внутренний API.

Это не говоря уже про всякие конфликты библиотек. Но откуда дедушкам об этом знать?

Действительно. Дедушки иксы перезапустить не могут отдельно, да, кудаж им, дедушкам...

И да, давайте теперь ещё ДЕ в основу ОС вкрячим, чтоб и на серверах. Истинный systemd-style, в свалке systemd только DE и не хватает, это ты правильно уловил. Пусть будет systemd-de ещё, и убрать все эти KDE/Gnome/XFCE/разное.

Ну то есть другим можно, а системд ты не любишь, поэтому нелья?

На это надо время тратить. На resolved не надо.

Каких клиентов, он на локалхосте.

Ну то есть другим можно, а системд ты не любишь, поэтому нелья?

Кому «другим»? Бузибоксу? Да можно. DE? Пофиг на DE, им на серверах делать нечего, да и выбор есть. Ядро? Ядер может быть больше одного, и возврат на старое можно делать по reset хоть в lilo, хоть в grub.

Кто ещё эти твои «другие», чтобы от этого зависело вообще всё? Или ты ещё сейчас начнёшь предлагать btrfs, снапшоты и загрузку с бакапного снапшота при каждом обновлении этого вашего ненужнод?

Кто ещё эти твои «другие», чтобы от этого зависело вообще всё?

coreutils

coreutils

В каком месте? Разные пакеты с util-linux (ethtool, если что, тоже пока отдельно ;-) ):

$ rpm -qa| grep "coreutils\|util-linux"
util-linux-2.39.2-alt2.x86_64
coreutils-9.4.0.75.7f2c97-alt1.x86_64
util-linux-control-2.39.2-alt2.noarch

В каком месте?

Если у тебя баг в одной из утилит coreutils, обновить тебе придется весь пакет. Ну или я не понимаю чем тебя пакет systemd угнетает.

Действительно. Дедушки иксы перезапустить не могут отдельно, да, кудаж им, дедушкам…

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

И да, давайте теперь ещё ДЕ в основу ОС вкрячим, чтоб и на серверах.

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

Короче, ты выхватил слово «reboot» и зацепился за него, не понимая сути вопроса. Типичный безграмотный systemd-хейтерок.

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

У разработчиков systemd Л - логика.

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

Чтобы системдэ и без проблем? Такого ещё не бывало.

C твоей квалификацией это совершенно неудивительно. Ты бы и 2 стеклянных шара умудрился пролюбить.

Если у тебя баг в одной из утилит coreutils, обновить тебе придется весь пакет. Ну или я не понимаю чем тебя пакет systemd угнетает.

Ты правда не понимаешь? Тем, что systemd тупо больше, а приложения там гораздо менее связанные. Или systemd весь мозг выел, и этого не понять?

И то, что обновление любого из них в составе операции dist-upgrade (либо аналогичному) ведёт к смене версии «systemd --version» хотябы в части дистрибутивного релиза и, как следствие, его перезапуску всегда. И когда надо, и когда не надо. А теперь можешь затянуть шарманку «это ваши менеджеры пакетов виноваты», с таким хорошим systemd жить мешают.

Опять же, к перезапуску какой кучи демонов ведёт обновление coreutils? В каком месте обновление coreutils может немедленно лишить доступа к серверу?

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

Может. Но, скорее всего, он её давно загрузил, и будет новой версией пользоваться только после собственного перезапуска. Но, что главное, он сам ни разу не PID 1. А уходящую в reboot систему при обновлении systemd я видел (то есть это сам systemd её в ребут отправил, успев ещё и в лог отчитаться). С разломом системы, так как в середине обновления. Сейчас ты скажешь, что это у мантейнера пакета руки кривые, не заметил засады в куче говна. Ну да, не заметил. Но с sysvinit такого не бывало просто ввиду дизайна и минимализма. Да его можно просто не обновлять на каждый чих.

У меня на ляптопе два VPN (в нормальном смысле) – на работу и домой. Чтобы это все нормально работало, кто-то должен уметь различать на какие DNS-серверы посылать запросы – эту задачу resolved и решает.

У некоторых коллег разных рабочих VPN-ов немного больше 2х. Везде страдания (даже на боготворимых маках), кроме рабочих станций с linux с systemd-resolved + nm.

Как только твоя сеть становится сложной, быстро начинаешь любить systemd ;))

Может.

Что и требовалось доказать.

скорее всего, он её давно загрузил

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

он сам ни разу не PID 1

Большая часть компонентов systemd тоже ни разу не PID 1.

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

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

с sysvinit такого не бывало просто ввиду дизайна и минимализма

Открой для себя man inittab и увидь ключевые слова про управление питанием и респаун. Дедушки изначально намеревались сделать что-то похожее на systemd, только не особо получилось. А теперь всякие ламеры бегают и рассказывают о том, как прекрасен был SysV init.

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

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

Единственная проблема здесь - избежать возможного конфликта с библиотеками при обновлении. Эту проблему и решаем.

Открой для себя man inittab и увидь ключевые слова про управление питанием и респаун. Дедушки изначально намеревались сделать что-то похожее на systemd, только не особо получилось. А теперь всякие ламеры бегают и рассказывают о том, как прекрасен был SysV init.

Вот ты и открой, и вчитайся. У меня речь совсем не про это.

Сервера с критической функциональностью обычно обновляются по расписанию, а потом ребутаются

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

Без systemd никакого расписания не надо было, да даже присутствия не надо было рядом годами.

Единственная проблема здесь - избежать возможного конфликта с библиотеками при обновлении. Эту проблему и решаем.

Вот! А для этого просто не надо было валить всё в кучу. Зачем journal в общем дереве исходников? Кто заставил udev втягивать? Ну и так далее. KDE, оно DE, и то на раздельно обновляемые компоненты разбили.

Вот ты и открой, и вчитайся. У меня речь совсем не про это.

Мне-то зачем? Я его читал, в отличие от тебя.

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

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

Без systemd никакого расписания не надо было, да даже присутствия не надо было рядом годами.

И сейчас точно так же не надо. У меня есть сервер без возможности осуществить к нему физический доступ, совсем. Так вот получилось. Работает на арче с systemd, полет нормальный.

Зачем journal в общем дереве исходников?

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

Кто заставил udev втягивать?

Потому что юнитам необходимо реагировать на события, связанные с устройствами.

Ей богу, всё десять раз уже обсуждалось, отмотай тред на первую страницу и внимательно читай.

Пользуешься дистром без тестинга или сам на нем сидишь - ССЗБ. Никакая система, в таком случае, от глюков не застрахована.

И да, я на вас пока смотрю, у меня ещё ни одного сервера в принципе с systemd нет. Вытаптывайте грабли, вытаптывайте. А я ещё подожду. Вот, может под бакапы сделаю первый на днях и поставлю поближе. ;-)

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

Кто мешал сделать отдельно библиотеки, отдельно systemd, отдельно journald? Кто мешал не пересобирать systemd и journald, если в библиотеках исправления, которые не ломают ABI? Почему вся разработка построена так, что надо пересобирать все подпакеты разом?

Ты правда не понимаешь? Тем, что systemd тупо больше, а приложения там гораздо менее связанные. Или systemd весь мозг выел, и этого не понять?

Правда не понимаю. Он 30 мегабайт весь целиком занимает. Какая разница насколько приложения связанные?

И да, я на вас пока смотрю, у меня ещё ни одного сервера в принципе с systemd нет.

И не будет. Ты будешь вечно отговорки находить, как и другие хейтерки.

Кто мешал

Потому что принятый подход - это архитектурный баланс между требованиями и простотой разработки. Вот и всё.

Как только твоя сеть становится сложной, быстро начинаешь любить systemd ;))

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

Правда не понимаю. Он 30 мегабайт весь целиком занимает. Какая разница насколько приложения связанные?

systemd головного мозга во всей красе.

Дело не просто в объёме кода, дело в количестве приложений (udev, journal, resolvd и ещё 100500), необходимость обновления которых влияет на ненужное в каждый из этих моментов обновление _работающего_ PID 1 (сам systemd). И его же ненужный перезапуск.

Потому что принятый подход - это архитектурный баланс между требованиями и простотой разработки. Вот и всё.

В общем неосиляторы.

Дело не просто в объёме кода, дело в количестве приложений (udev, journal, resolvd и ещё 100500), необходимость обновления которых влияет на ненужное в каждый из этих моментов обновление работающего PID 1 (сам systemd). И его же ненужный перезапуск.

Зачем ты перезапускаешь systemd обновляя resolved? Это разные процессы.

Зачем ты перезапускаешь systemd обновляя resolved? Это разные процессы.

Потому, что когда ты пересобираешь systemd-%version-%release.src.rpm ради того, чтобы наложить патч на любой из компонентов, у тебя в репозитории обновляются %release всех полученных бинарных подпакетов, включая сам systemd, даже если их это не касается.

Ты на точечных обновлениях живёшь попакетных, или, всё же, полное обновление делаешь, а-ля dist-upgrade? Дальше объяснять?

или ты вовсе ручками отдельные бинарники копируешь себе?

Потому, что когда ты пересобираешь systemd-%version-%release.src.rpm ради того, чтобы наложить патч на любой из компонентов, у тебя в репозитории обновляются %release всех полученных бинарных подпакетов, включая сам systemd, даже если их это не касается.

Это делает мейнтейнер.

Ты на точечных обновлениях живёшь попакетных, или, всё же, полное обновление делаешь, а-ля dist-upgrade?

Это делает бездушная машина.

Дальше объяснять?

Да, я все ещё не вижу проблемы.

Ты на точечных обновлениях живёшь попакетных, или, всё же, полное обновление делаешь, а-ля dist-upgrade?

Это делает бездушная машина.

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

Да, я все ещё не вижу проблемы.

Частый перезапуск сервиса, из-за которого может навернуться вообще всё, для тебя не проблема? Ну-ну. Или ты так поклоняешься разработчикам sustemd, что считаешь их непогрешимыми богами программирования и веришь в успешный перезапуск?

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

И что?

Частый перезапуск сервиса, из-за которого может навернуться вообще всё, для тебя не проблема?

Да вообще плевать. Ни разу не падало.

Ну-ну. Или ты так поклоняешься разработчикам sustemd, что считаешь их непогрешимыми богами программирования и веришь в успешный перезапуск?

Почему тебя не смущает рестарт nginx и postgresql, которые куда более сложные и от которых реально зависит бизнес?

Беглый поиск в Сети дает такое:

«Client applications send name resolution requests to systemd-resolved via the NSS resolve module, which is configured in /etc/nsswitch.conf.»

«Client applications send name resolution requests to systemd-resolved via the NSS resolve module, which is configured in /etc/nsswitch.conf.»

Ага, все такю

Этот дистрибутив ставить себе не буду, но, тем не менее, я за то, чтобы было разнообразие.

Потому что =на каждого, кто пляшет русалочьи пляски, есть тот, кто идет по воде=. В этом контексте мне понравился вот этот ответ в треде - Devuan Excalibur 6 (комментарий)

Почему тебя не смущает рестарт nginx и postgresql, которые куда более сложные и от которых реально зависит бизнес?

Потому, что если они грохнутся, можно зайти по ssh и поднять. А если грохнется init, то только бежать ножками. Иногда много километров. Или не очень много, но по пробкам.