[devel] I: systemd-248.3-alt2 и конфликт со startup

[Anton Farygin]

On 08.07.2021 18:46, Alexey Gladkov wrote:
> On Thu, Jul 08, 2021 at 04:52:17PM +0300, Anton Farygin wrote:
>> On 08.07.2021 16:37, Alexey Gladkov wrote:
>>> On Thu, Jul 08, 2021 at 03:18:32PM +0300, Anton Farygin wrote:
>>>> On 08.07.2021 15:13, Sergey Afonin wrote:
>>>>> On Thursday 08 July 2021, Anton Farygin wrote:
>>>>>
>>>>>>> А не страшно пользоваться взрывающейся модной системой инициализации?
>>>>>>> Мне вот как-то не очень уютно. Уже несколько раз взрывалась на ровном
>>>>>>> месте.
>>>>>> А известно на чём взрывалась ? Ошибки зарегистрированы в нашей bugzilla ?
>>>>> Последняя серьёзная да, и исправлена. Но сколько их ещё вылезет? Остальные
>>>>> достаточно старые, можно считать, что было давно.
>>>>>
>>>> Вы думаете, что во времена активной разработки sysvinit никогда не было
>>>> серьёзных ошибок и взрывов ?
>>>>
>>>> Ошибки возможны в любом продукте, который развивается.
>>> Да сколько угодно. К сожалению наиболее интересные скрыты за security, но
>>> вот пример баги, которая висит с 2011:
>>>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=739538
>> О, и тут Шигорин ;)
>>
>> А давай посмотрим на другое - вот прошло 10 лет, и за 10 лет это явно не
>> привело ни к каким проблемам (особенно при наличии конфигурационной опции).
> О. Антон, тебе бы к нам работать нужно идти с такой логикой. Мой прошлый
> лид тоже считал, что бага не является security до тех пор пока
> какого-нибудь заказчика не ломанут. Вы поладите я думаю.
>
> Ну и нет никакой опции. Можно просто выключить логи для сервиса вообще.
>
> Сейчас же многие такие проблемы просто публике не показывают. Они
> приватные. Это в далёком 2011 такое публично сделали.
Понятно. Жаль, конечно.
>
>> На системе с sysvinit тоже можно сделать сервис, который будет выжирать всю
>> память от воздействия снаружи. Это же не проблема sysvinit ?
> Можно. Правда это не приведёт к выжиранию всей памяти процессом с PID=1.
Да, верно, но к сожалению системе от этого легче не будет ;(
>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1977661#c2 -- а вот пример
>>> компетенции сопровождающих. Это не единичный случай.
>> Я не понял, про компетенцию. Перечитал тред - у человека починилось с
>> обновлением ядра. Или я что-то не то смотрю ?
> Я говорил про подход "No idea what was the cause, though". И повторюсь это
> не единичный случай, когда ответственные так реагируют на проблемы.

Блин, как будто у нас таких проблем нет.

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

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


>
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1967457 -- вот эта просто мне
>>> близка.
>> Да, забавно. Но это опять же больше похоже на баги в обвязке, а не в самом
>> /sbin/init и у нас всякие подобные тоже были на sysvinit.
> Не так давно товарищи предлагали не выдавать ошибку в loadkeys, чтобы
> сервис не фейлился.
;) Смешно. С таким же успехом можно было бы заигнорить фэйл в сервисе ;)
>
>>> Из уважения к redhat я ограничусь лишь этой парой ссылок, но ты и сам
>>> сможешь легко найти много интересного в багзилле. У меня есть основания
>>> не пользоваться этим продуктом.
>>>
>> Да, я и в bugzilla проекта firefox/thunderbird на многое интересное
>> подписан, которое исправляется десятилетиями.
> Вот только это проекты с несколько разным уровнем критичности. Когда у
> меня ломается firefox я всё-таки могу что-то на машине сделать.
Смотря что надо делать, для меня сейчас поломка почты и браузера даже 
более критична поломке init 1, т.к. с ним то как раз я знаю что делать 
;( А вот ошибка в  профиле thunderbird съела мой рабочий день пару лет 
назад.
>
>> Для себя то как раз не проблема сделать нужную конфигурацию, вплоть до
>> сборки из исходников всех необходимых компонент.
> То есть ты предлагаешь мне валить на gentoo ?
зачем на gentoo ?
>
> Ты спросил про баги. Я тебе показал баги, способные завалить init, которые
> не закрываются годами. В ответ ты говоришь, что раз 10 лет висят, то ОК, а
> то что из того же проекта, но не PID=1, то это вообще про другое.
>
> Но мы же сравниваем init. Давай теперь ты мне покажешь баги sysvinit, а не
> обвязки, приводящие к краху системы ?

Время для багов sysvinit прошло в тех самых 90-х, когда остановилась его 
разработка. Наверное, поискать можно и возможно даже получится найти, но 
станет ли нам от этого легче ?