nixp.ru v3.0

26 мая 2017,
пятница,
04:53:54 MSK

DevOps с компанией «Флант»
Аватар пользователя rgo
rgo написал 27 ноября 2014 года в 12:31 (3295 просмотров) Ведет себя неопределенно; открыл 61 тему в форуме, оставил 1602 комментария на сайте.

Взялся я тут ознакомиться с systemd, но надоело спотыкаться на ровном месте. Есть ли какое-нибудь обзорно-вводное руководство, которое бы не гоняя меня из одного man’а в другой, последовательно бы изложило где какие файлы лежат, и как решаются базовые задачи по настройке системы.
Ну, например, я поставил систему и поставил её без свопа вообще. systemd начал при каждой загрузке устраивать паузу на полторы минуты, в ожидании когда подключится своп. Я уж и disable на dev-SWAP.target попробовал, и так и эдак — ничего не помогает. И лишь затем, расковыряв проблему поглубже, я выяснил что всё из-за sysinit.target, которая требует swap. Проблему решил скопировав в /etc/systemd/system/ файлик sysinit.target, и подредактировав его. И тут есть два косяка: 1) час биться головой об клавиатуру, чтобы решить такую мелочь — это не гут; 2) я не уверен, что способ найденный мною — «правильный» способ. Правильный в том смысле, что может существует другой, более удачный с идеологической точки зрения, способ?
Об --global я также споткнулся. Читая man, понял что эта опция нужна, чтобы включать и выключать сервисы навсегда, но долбаный systemctl видя такую опцию, тупо завершася с ошибкой «File not found», не поясняя даже того, какой именно файл им не был найден. Перечитал man, и понял что читал я криво, и речь идёт не о сохранении конфигурации между перезагрузками, а о чём-то недоступном мне на текущем моём понимании функционала systemd (применение конфигурации ко всем логинам юзеров).
И на фоне всего этого, как раз и возникла мысль, что было бы неплохо иметь под рукой что-нибудь типа туториала, который бы описал как можно работая с systemd получить систему из какого-нибудь пускай не очень широкого, но всё же спектра. Со свопом, без свопа, с сетью или без неё. А initamfs? По некоторым признакам я понял, что и в initramfs можно засунуть systemd, чтобы тот начинал конфигурировать систему ещё до того, как рут смонтирован, но как это сделать? Как настроить? Мне это, так уж получилось, не надо (у меня / и /usr на одном разделе), но а если бы надо было бы?
Всё что я нахожу о systemd — это либо его man’ы, либо какие-то разрозненные куски информации, сводящиеся к одной-двум фразам вида «если в этот файлик написать A, то будет Б». А какого-то обзора, который бы позволил сделать шаг в сторону и разглядывать не отдельные деревья, а весь лес в целом (ну или хотя бы сколь-нибудь репрезентативную часть его) — я никак не могу найти.

arhimedoffs

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

rgo

Я тоже не знаю, пока по-крайней мере, стоит ли им пользоваться. Вообще приятные плюшки есть, но на данном этапе оно больше бесит и раздражает тем, что те задачи которые я обычно делаю влёгкую и не задумываясь, теперь требуют кучи усилий по исследованию systemd. Раздражает до той степени, что меня уже начало бесить слово system, которое при работе systemd везде, что в /usr/lib/systemd/system заглянуть, что systemctl или systemd-networkd набрать… у-у-у, суки… Было бы лучше если бы они взяли что-нибудь покороче и вообще отличное от system, чтобы не было этих повторов. И всё это наводит на мысль, что прежде чем выносить вердикты, надо дождаться этапа, когда вся эта шелуха станет привычной и поэтому несущественной.

fhunter

Собственно описанное и останавливает от использования.

Если с init-ом я могу просто проследить вообще весь процесс от inittab и до нужного скрипта, не залезая в исходники. (Ок, в Slackware скрипты были намного проще). То в systemd — не пройдёт.

Аналогично с другими «новыми системами». Почему один релиз debian-а назад, для того чтобы дать доступ на флешки/аудио/видео/прочие порты локальным пользователям, я просто дописывал нужные группы в pam_group, а сейчас мне надо читать и писать нечеловеко-читаемые xml-ки policykit-а? Нет, pam_group не сломался, он просто стал работать только из консоли. А DE упорно считает что если policykit не дал прав — то и работать нельзя и прав смонтировать нет.

rgo

Вы уж простите, но ваша позиция по-большей части напоминает: «я умею разбираться со скриптами, а с systemd — нет, и не хочу учиться.» Я, ковыряясь с systemd, пока ещё не доходил до нужды ковыряться в исходниках systemd. По-хорошему, если бы я изначально сделал бы забег по man’ам systemd и просто их прочитал бы внимательно, то проблем у меня было бы резко меньше. Я не сделал этого, потому что этих манов — хоть жопой жуй, и априори было совершенно не ясно что из того необходимо прочитать, а что можно оставить на потом и прочитать при случае, когда понадобится. Это стандартная проблема возникающая при столкновении с любой незнакомой системой, будь то система инициализации, или что-то ещё.

Во-первых, man’ы содержат разрисованный граф загрузки, в котором указаны все special unit’ы, их зависимости и порядок. Да, это куча информации, которую необходимо усвоить для того, чтобы этим systemd пользоваться, но сравнивая с sysvinit/openrc я отмечу, что они для работы с ними требуют, быть может, не меньше знаний, другое дело что знания требуемые для работы с openrc/sysvinit уже находятся в моей голове. Во-вторых, systemctl позволяет исследовать зависимости из командной строки: узнать каким путём systemd пришёл к идее загрузить тот или иной unit несложно. Просто есть нюансы — special unit’ы, например тот который ответственен за swap: он срабатывает не только из-за завимостей между unit’ами, но и ещё из-за того, что прописано в /etc/fstab. Мой же косяк оказался в том, что я как-то совершенно беспочвенно считал, что если я в fstab не прописывал свопа, то его там и быть не должно. И мне даже в голову не пришло сказать cat /etc/fstab, чтобы проверить свои предположения. Два балла по рациональности, за неумение исследовать окружающую реальность и приводить свои представления о реальности в соответствие с реальностью. :)

То есть, всё равно, по-моему, это залёт: если своп не подключить или что-то там не смонтировать, то по-моему не стоит на полторы минуты тормозить загрузку. Но эти полторы минуты настраиваются. Правда глобально: может и можно per unit указывать время ожидания, но я не замечал ничего подобного в документации. С другой стороны надо признаться, я пока не заморачивался вопросами как писать unit-файлы — этот кусок документации я просто пролистал, схватив только основные идеи.

fhunter

Моя позиция — init работает, документирован и прост. И устраивает. Допишут systemd до стабильного, документированного состояния — посмотрим.
А так как на сервере включены квоты, то мне глубоко всё равно — быстро он грузится или не очень. Если некорректно был выключен, всё равно будет проверять квоты минут 40, и домашних каталогов всё это время не будет. А если был выключен корректно — то общее время загрузки порядка минуты, что на фоне их частоты — пренебрежимо мало.

PS. Мне не нравится не то, что изучать надо, а то что его впихивают безальтернативно.

rgo

Хех. Со свопом всё оказалось до идиотизма смешно. stage3 генты содержит некий fstab созданный типа для примера, в нём были прописаны /dev/ROOT в качестве /, и /dev/SWAP в качестве свопа. Я этого не замечал пока система на openrc стартовала — вероятно там какие-нибудь ошибки fsck и swapon вылезали в процессе, но я просто не успевал разглядеть. Ну а systemd упёрто пытался подключить своп, хотя дело это было безнадёжное.

Бинарными логами тоже пугали-пугали, а на деле оно оказывается не так печально: journalctl, если без опций его запускать, выводит в stdout содержимое лога в текстовом формате. Причем, если stdout — это tty устройство, то он ещё через $PAGER запускает. В общем, я бы не сказал что с логами стало работать сложнее, вручную ли или скриптами.

fhunter

Бинарные логи проблема не при чтении, а как потенциальная проблема при крахе системы. Текст остаётся читабельным при повреждении файла. Останется бинарный лог читабельным в этом же случае?

rgo

Что вы имеете в виду, говоря о «читабельности»? О возможности прочитать этот файлик из busybox-шелла initrd? Я чесслово не знаю — до запиливания systemd в initrd я пока не добрался. Как доберусь — доложу. Вообще, навскидку:

ldd `which journalctl`
        linux-vdso.so.1 (0x00007fffeb9fe000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f326b8da000)
        libacl.so.1 => /lib64/libacl.so.1 (0x00007f326b6d2000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f326b4b5000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f326b110000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f326bae2000)
        libattr.so.1 => /lib64/libattr.so.1 (0x00007f326af0b000)

То есть, по-сути, лишь libc в депендансах, что даёт надежду на то, что journalctl можно собрать и под busybox. Отдельным вопросом идёт то, насколько это геморно, и возможно ли это сделать не занимаясь копированием .c файлов оттуда сюда, переписыванием makefile’ов, и прочей лабудой… Хотелось бы, конечно, чтобы этот вопрос решался лёгким шаманством с use-флагами systemd. А лучше даже и без него. Но, посмотрим.

fhunter

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

rgo

«Бинарный формат можно криво спроектировать, поэтому бинарный формат — это зло.» А разве текстовый формат нельзя криво спроектировать? Можно например, дописывать строчки не в конец файла, а в начало. Значит и текстовый формат плохой?

Давайте определимся вот с чем. Если вы имеете целю своей агитацию против systemd, то займитесь этим где-нибудь в другом месте. Поймите, я взялся разбираться с systemd самостоятельно именно из-за таких как вы, кто любое упоминание systemd рассматривает как агитацию «за» или «против». Если бы вас не было, то я бы просто взял, почитал бы о systemd в интернете и либо поставил бы его сразу себе на систему, либо просто забыл о его существовании. Но поскольку вы есть, и вы засрали вообще всё своими агитациями «за»/«против», то я вынужден заниматься этим самостоятельно.

А вообще, я бы рекомендовал вам почитать эту статью, либо сразу всю цепочку статей. Или даже все цепочки здесь, начиная сверху и вниз до окончания цепочки «политика — убийца разума.» Если читать вдумчиво, примеряя к своему опыту познания окружающего мира и участия в срачах различных тематик, то это превосходно прочищает мозги от всего агитационного мусора, политики, религии и прочего догматизма. Но… ACHTUNG! ACHTUNG!: оно действительно может прочистить мозги от религии, и если у вас есть какие-либо «религиозные» взгляды, которые вам дороги как память, и лишиться которых вам будет очень неприятно, то лучше забейте и не читайте ничего. Например, если ваше неприятие systemd вам действительно важно и вы не хотите его лишиться ни в коем случае, то не читайте. Если вы прочитаете, то запросто может выйти так, что в дальнейшем обсуждении systemd здесь или где-то ещё вы утратите это неприятие. Может быть и не утратите: я пока не имею определённого мнения о systemd, но именно из-за отсутствия своего собственного мнения о systemd я и пишу это предупреждение: я не могу вам дать гарантий того что вы не станете внезапно systemd-фанбоем. Впрочем, если читать вы будете внимательно и осознаете прочитанное, то фанбоем чего-либо или кого-либо вам уже вряд ли когда-нибудь удастся стать.

fhunter

Ух ты, какая прелесть. Обязательно почитаю. Спасибо. Выглядит любопытно. (Удаляюсь качать на читалку)…

Удачи в раскопках.

PS. Пожалуй я действительно перебрал с дискуссией по поводу systemd (последние посты). Этот пост будет финальным.
PPS. Форматы — это довольно интересная тема. Чем он минималистичнее, тем проще с ним работать. (Но я обещал прочитать текст и я ушёл его читать).

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

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