LINUX.ORG.RU
Форум — Talks  

Этот ваш systemd...

 , закон мерфи, от простого к сложному


2

2

Решил проапдейтить федору до 21. yum update; yum --releasever=21 update, и вперёд. В середине апдейта внезапно происходит...

Dec 11 12:26:13 localhost kernel: systemd[1]: segfault at 20 ip 00007fec86e29b36 sp 00007fff9c917110 error 4 in systemd[7fec86d9a000+137000]
Dec 11 12:26:13 localhost systemd: Caught <SEGV>, dumped core as pid 27322.
Dec 11 12:26:35 localhost su: (to root) viking on pts/1
Dec 11 12:26:38 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Dec 11 12:26:38 localhost systemd-logind: Failed to start user slice: Activation of org.freedesktop.systemd1 timed out
Dec 11 12:27:03 localhost systemd-logind: Failed to start user service: Connection timed out
Dec 11 12:27:03 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Dec 11 12:27:03 localhost systemd-logind: Assertion 's->user->slice' failed at ../src/login/logind-session.c:496, function session_start_scope(). Aborting.
Dec 11 12:27:28 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Dec 11 12:27:48 localhost dbus[782]: [system] Activating systemd to hand-off: service name='org.freedesktop.PackageKit' unit='packagekit.service'
Dec 11 12:27:53 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Dec 11 12:28:13 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.PackageKit': timed out
Dec 11 12:28:18 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Dec 11 12:28:43 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out
Dec 11 12:29:08 localhost dbus[782]: [system] Failed to activate service 'org.freedesktop.systemd1': timed out

Всё. Писец. Система стремительно теряет реакции на внешние раздражители, в конечном итоге не реагирует ни на что, yum повисает, systemctl не работает, сеть отваливается, reboot - хрен там. Перезагрузка, yum-complete-transaction - все пакеты в двух версиях, новой и старой (а их, пакетов, более 2000). Далее шаманские танцы с принудительным апдейтом всего с использованием кэша юма, потеря конфигурации grub, восстановление оной - но это уже лирика.

Так вот, что я хотел сказать то? А вот что - это первый звоночек. Не надо было превращать простое (реально простое!) в сложное. Всё, что надо было сделать - оторвать init от systemd. init должен быть отдельным процессом, который стартует systemd и по сигналам (или при падении) его рестартовывывает. А собственно неубиваемое маленькое ядро самого инита уронить было бы практически невозможно.

★★★★★

fedora 21 - ничего удивительного.

invy ★★★★★
()

Ты первый раз увидел в софте на С ошибку?

powerguy ★★★
() 
su: (to root) viking on pts/1

Да у тебя же...

Adonai ★★★
()
Последнее исправление: Adonai (всего исправлений: 2)

Так вот, что я хотел сказать то? А вот что - это первый звоночек.

федора это не первый звоночек, это последний

Deleted
()

Вчера на работе сделал с Федорой то же самое, все прошло гладко, без сучка и задоринки, хотя у меня очень кастомный десктоп с кучей наворотов. Перезапустился, и у меня новая Федора. А где-то неделю назад, когда 21 еще не вышла, сделал это на домашней машине. Единственный косяк - RPMFusion подхватился от rawhide, надо будет его как-то уконтрапупить. Может проблема, таки, не в systemd была?

Хотя, истина в том, что ты говоришь есть, несомненно. Не нравится мне, что какая-то бодяга вывела из строя systemd, после чего система стала абсолютно неконтролируема и половина всего поотваливалась, включая yum. Время идет, решаемые задачи усложняются, отчего усложняются и системы, которые эти задачи решают. Ничего не поделаешь.

alex_the_v ★★★
()

Тут на opennet ещё новость валяется, что в systemd впихнули поддержку pppoe, так что ждём историй «успеха». Возможно, я сам успею её рассказать.

grem ★★★★★
()

Всё, что надо было сделать - оторвать init от systemd. init должен быть отдельным процессом, который стартует systemd и по сигналам (или при падении) его рестартовывывает.

Так для этого мозги должны быть. Поцтеринг в этом не замечен, однако.

Motif ★★
()

Смысл в этом «разделении» какой? После подыхания супервизора систему всё равно придётся уводить в ребут.

У тебя всё повисло не потому что systemd «утащил всё за собой», а потому что каждый компонент, включая yum, пытается до него достучаться по шине. А до упавшего процесса достучаться нельзя никак, будь он хоть тысячу раз разделён и изолирован.

Если ты заметил, то при падении у тебя не случилось паники ядра, хотя должна была. Это потому что systemd ловит все сигналы. А из обработчика сигнала запросто можно сделать и exec() новой копии systemd, и никакой отдельный инит для этого не нужен. Проблема там совершенно в другом — чтобы перезапустить упавший супервизор, нужно сериализовать его состояние, а после сегфолта состояние уже считается повреждённым и верить ему нельзя. Можно перезапустить супервизор с чистым состоянием — но здесь уже будет лучше рестартнуть систему целиком. Вот потому я и говорю, что вышеотписавшиеся хейтеры типа Motif тупо некомпетентны.

А баги нужно репортить и исправлять.

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 2)
Ответ на: комментарий от grem

в systemd впихнули поддержку pppoe

В systemd-networkd.

Gotf ★★★
()
Ответ на: комментарий от intelfx

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

С фига ли? Систему можно сводить в ребут, но это совсем не обязательно.

Если ты заметил, то при падении у тебя не случилось паники ядра, хотя должна была. Это потому что systemd ловит все сигналы. А из обработчика сигнала запросто можно сделать и exec() новой копии systemd, и никакой отдельный инит для этого не нужен. Проблема там совершенно в другом — чтобы перезапустить упавший супервизор, нужно сериализовать его состояние, а после сегфолта состояние уже считается повреждённым и верить ему нельзя

Тут ты вообще не прав.

systemd слишком сложен (ldd /usr/lib/systemd/systemd) и завязан на слишком дофига всего, поэтому в нем слишком много «точек отказа» (dbus/libz/pcre и куча всего ещё). https://ru.wikipedia.org/wiki/Systemd#mediaviewer/File:Systemd_components.svg

Например, достаточно просто бага в nss (который используется для разрешенияloginname <-> uid и groupname <-> gid), чтобы systemd превратился в тыкву. Вместе с системой.

А теперь представим, что systemd все ключевые изменения своего состояния (а их немного) передает через неименованный канал или сокет во внешний init, а при старте считывает из этого же init'а предыдущее состояние? Всё, проблема решена. Теперь systemd может убиваться, перезапускаться, виснуть - делать всё что угодно, в общем. Система от этого не пострадает.

kill -HUP 1 - перезапустился systemd
kill -USR1 1 - запустился /sbin/initalarm1
kill -USR2 1 - запустился /sbin/initalarm2

systemd что-то изменил в состоянии системы? Отправил извещение формата <идентификатор группы, новое состояние, имя сервиса> в init. systemd запустился? Запросил из init'а список текущих состояний, init его ему предоставил.

no-dashi ★★★★★
() автор топика
Ответ на: комментарий от no-dashi

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

Ок, вероятно, названная мной «проблема» проблемой не является. Тем не менее, всё, что можно сделать с помощью разделения systemd на инит и супервизор, можно сделать и без этого. Значит, там есть какие-то другие проблемы, о которых я не осведомлён.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

Ну скажем так - косяк в ядре не лечится вообще никак, но никакое событие в юзерспейсе (кроме падения процесса с PID=1) не должно приводить систему в неконтролируемое состояние. Достигнуть этого можно можно максимальным упрощением кода, который выполняется в PID=1.

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

no-dashi ★★★★★
() автор топика

Решил проапдейтить федору до 21

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

Komintern ★★★★★
()
Ответ на: комментарий от no-dashi

systemd не простой и изоляция компонентов в нем оставляет желать лучшего.

нельзя на одной странице сочетать systemd, изоляцию и модульность. ты же не жаришь шашлыки на НПЗ!

der_looser ★★
()
Ответ на: комментарий от intelfx

а потому что каждый компонент, включая yum, пытается до него достучаться по шине

Вот нахрена пакетному менеджеру стучаться в него? Раньше же он как-то работал и со своими задачами справлялся?

Harald ★★★★★
()
Ответ на: комментарий от intelfx

Ты тоже не замечен, да.

Тебе сколько раз уже говорили о ненормальном количестве кода в PID 1? Глючного и неотлаженного, так как иного у Поца не бывает, пульса подтверждает.

В общем ты еще просто школота, не видевшая реальности. Еще все впереди, да.

Motif ★★
()
Ответ на: комментарий от Motif

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

Marlboro ★
()
Ответ на: комментарий от Harald

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

intelfx ★★★★★
()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от Motif

Тебе сколько раз уже говорили о том, что это количество «ненормально» только в твоём понимании, а «так как иного не бывает» — не аргумент?

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

Что мешает запустить «systemctl что-то там» как в этих ваших поттерингокуппированных дистрах теперь принято? Зачем какую-то шину использовать?

Да и вообще нужность перезапуска сервисов пакетным менеджером сомнительна. Вот в генте portage сервисы не трогает, юзер сам решает, что и когда запускать или останавливать.

Harald ★★★★★
()
Ответ на: комментарий от Harald

А каким, по-твоему, образом, systemctl общается с инитом?

Более того — в скриптах пакетного менеджера наверняка systemctl и используется. Но не знаю, потому и сказал «по шине», чтобы не ограничивать общность почём зря.

intelfx ★★★★★
()
Ответ на: комментарий от Harald

Да и вообще нужность перезапуска сервисов пакетным менеджером сомнительна.

Не перезапускать, а перечитывать конфигурацию. Чтобы юзер, когда сам решит что-нибудь (пере)запустить, смог это сделать.

intelfx ★★★★★
()
Ответ на: комментарий от Harald

Я говорю про перечитывание списка юнитов, т. е. конфигурации _systemd_.

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

Ну вон ТС на практике убедился и в качестве, и в количестве.

А вот УМВР это реально не аргумент. Pulseaudio все помнят, мифологию разводить бесполезно.

Motif ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Talks