Разборки с systemd 24

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

Вы уж простите, но ваша позиция по-большей части напоминает: «я умею разбираться со скриптами, а с 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-файлы — этот кусок документации я просто пролистал, схватив только основные идеи.

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