LINUX.ORG.RU
ФорумTalks

Arch, Gentoo. Документация и порог вхождения.

 , ,


0

1

Логотип Arch Linux давно не давал мне покоя и сегодня ночью я решил предпринять вторую попытку. Тем более, что тогда я, похоже, просто не догадался для Virtuabox установить пакет, который сейчас называется xf86-video-vmware (WAT!?).

Раньше у Arch была расширенная версия инструкции по установке «Beginners’ guide» - насколько помню, достаточно подробное руководство, которое ничем не уступало Gentoo Handbook. Сейчас по какой-то причине его больше нет. Из-за этого, если пользователь давно не устанавливал систему, то ему, к сожалению, придётся перечитать сначала кучу документации в arch wiki (она есть и действительно хорошая), а то и вовсе будет проще открыть gentoo handbook (я так не делал), который содержит более подробные инструкции.

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

Из раздела настройки сети парой переходов можно добраться до статьи о dhcpcd, где сообщат, что сервис нужно start/enable и отправят читать статью о systemd, не приводя примера команды о_О. Серьёзно, после окончания настройки системы я могу не трогать сервисы годами, да и зачем?

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

Если опустить этот момент, то сам процесс установки даже упростился. На этапе установки набора base не предлагают что-то прописывать в конфиг. Кажется раньше наборы в одном из файлов конфигурации нужно было указывать или я с чем-то путаю. После установки набора base (nano в нём тоже есть) я установил только grub, mc, virtualbox-guest-utils, xf86-video-vmware, plasma-desktop, konsole, dolphin, opera и получил готовое рабочее окружение. В целом процесс занял не больше чем занял бы в случае, например, debian net-install.

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

★★★★★

Ответ на: комментарий от grem

В 205 версии systemd была пачка багов, связанных с отслеживанием состояния цгрупп (которая усугублялась пачкой архитектурных проблем с cgroups v1 в ядре). Из-за этого systemd периодически начинал думать, что какой-то юнит ещё не завершился, хотя на самом деле процессов в цгруппе могло уже давно не быть.

С тех пор все эти баги давно исправили, а cgroups переписали с нуля.

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

Gentoo предполагает ручную правку fstab, сборку ядра и много прочего, поэтому хендбук нужен.

Старт сервисов, разбивка диска, dhcpcd — всё это есть и в условной убунте, и более-менее опытный пользователь линукса всё это знает. А для менее опытных есть manjaro/antergos/archbang и т.д.

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

Зачем вообще делать такой тайм-аут? Когда я вижу это сообщение (икс уже прибиты), то sddm уже должен был разлогинить пользователя и все его процессы уже должны быть завершены.

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

Сейчас не то же самое происходит?

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

Зачем вообще делать такой тайм-аут?

Потому что иначе на ЛОРе бы вопили «а вот у меняяяяя pre-IDE жёсткий диск с частотой вращения полоборота в минуту, шиштемде убивает базы данных аряяяя».

sddm уже должен был разлогинить пользователя и все его процессы уже должны быть завершены.

Из первого не следует второе. Таймаут в 90 секунд — между ними. Ваш кэп.

Сейчас не то же самое происходит?

Перечитай моё сообщение.

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

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

Если за 90 секунд не завершится то, ради чего сделан тайм-аут, то что? «системд убъёт базу данных» или сообщит id процесса, который не завершён?

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

Пока кажется, что просто ещё не всё баги, связанные с определением состояния, устранены.

Ты знаешь или тебе кажется? Если точно знаешь — милости просим в багтрекер.

Если за 90 секунд не завершится то, ради чего сделан тайм-аут, то что?

То процессам, которые не успели, прилетит SIGKILL.

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

Знаю, потому, что не сообщается о том, завершение какого процесса ожидается. То есть создаётся ощущение, что «ожидающему» самому неизвестно чего он ждёт. В баге 2013 года на это жалобы уже есть

The big question on my mind is: what is the stop job, exactly? What’s it waiting for? Why 90 seconds? Where (in the code) could I start bughunting? That’s more than one question, I guess. It’s frustrating that it doesn’t give a bit more info.

Мне сходить попросить его переоткрыть, если пару раз ещё натолкнусь?

То процессам, которые не успели, прилетит SIGKILL.

Зачем тогда ждать, если всё равно прилетит.

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

Знаю

Хреново знаешь.

не сообщается о том, завершение какого процесса ожидается

И не должно. Сообщается о том, завершение какого юнита ожидается. А завершение юнита — это опустошение цгруппы. Процессов там может быть 1 или 1000, systemd в общем-то нигде их список в явном виде не ведёт — этим занимается ядро.

В баге 2013 года на это жалобы

Жалобы от таких же неосиляторов, по ходу.

what is the stop job, exactly? What’s it waiting for? Why 90 seconds? Where (in the code) could I start bughunting?

А какого хрена он вообще полез в код, если он даже ман, судя по всему, не читал, раз не знает, что такое stop job, чего он ждёт и откуда взялось значение в 90 секунд?

Мне сходить попросить его переоткрыть, если пару раз ещё натолкнусь?

Первое, что у тебя спросят — это уверен ли ты в том, что это баг в systemd, а не в повисшем процессе. Так вот, ты уверен? Ты смотрел в цгруппу, или хотя бы в systemctl status по этому юниту параллельно с висяком?

Зачем тогда ждать, если всё равно прилетит.

В норме никаких SIGKILL’ов никому прилетать не должно.

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

Сообщается о том, завершение какого юнита ожидается.

Где? Не сообщает.

Жалобы от таких же неосиляторов, по ходу

Я понял твою позицию: если пользователю посчастливилось увидеть то сообщение при выключении системы, то он сам дурак и неосилятор.

судя по всему, не читал, раз не знает, что такое stop job, чего он ждёт и откуда взялось значение в 90 секунд?

От чтения мана сообщение вида «подожди, пока я жду не скажу чего» понятнее не станет.

То процессам, которые не успели, прилетит SIGKILL.

В норме никаких SIGKILL’ов никому прилетать не должно.

Так прилетит или нет?

Первое, что у тебя спросят — это уверен ли ты в том, что это баг в systemd, а не в повисшем процессе.

Конечно не уверен. Из сообщения вообще ничего понять нельзя. А оно выдаётся systemd. Очевидно, что начать нужно с него.

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

Где?

«stop job is running for UNIT»

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

Если он прибегает в багтрекер качать права, не прочитав даже ман, то да — он дурак и неосилятор.

То процессам, которые не успели, прилетит SIGKILL.

В норме никаких SIGKILL’ов никому прилетать не должно.

Так прилетит или нет?

Хватит шланговать. В норме все процессы укладываются в 90 секунд. Потому там и 90 секунд, а не 5 и не 10. Этот таймаут в норме не достигается и нужен для того, чтобы безнадёжно повисший процесс не мог заблокировать остановку системы навсегда.

Конечно не уверен

Гуляй, NEEDMOREINFO WORKSFORME WONTFIX.

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

«stop job is running for UNIT»

Ага, «stop job is running for session of user …» https://i.redd.it/k6ultfz617111.jpg

Сразу понятно, что дела плохи и «подождём мою маму».

Полно других таких картинок.

NEEDMOREINFO

Запросто, пишется что-нибудь из разряда: «Could you give the advise how I can provide the additional information?»

Гуляй, NOTABUG WONTFIX

В это охотно поверю, не впервой.

Хватит шланговать. В норме все процессы укладываются в 90 секунд. Потому там и 90 секунд, а не 5 и не 10. Этот таймаут в норме не достигается и нужен для того, чтобы безнадёжно повисший процесс не мог заблокировать остановку системы навсегда.

В том то и дело, что наиболее часто встречаемое предлагаемое решение «проблемы» - уменьшить тайм-аут, например, до 10 секунд. Поэтому не понятно, что именно послужило основанием закрытия тогр бага? То, что все забили опять о нём сообщать? Баг был в systemd или нет?

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

Ну алё, в самом начале же написал!

Arch, Gentoo. Документация и порог вхождения. (комментарий)

Это значит, что у тебя включено убийство процессов сессии при разлогине, но кто-то не реагирует на SIGTERM.

Пользовательская сессия — это тоже юнит.

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

Ага, «stop job is running for session of user …»

Смотри выше.

В том то и дело, что наиболее часто встречаемое предлагаемое решение «проблемы» - уменьшить тайм-аут

Угу, «решение». Решение уровня /lor/.

Поэтому не понятно, что именно послужило основанием закрытия тогр бага?

Arch, Gentoo. Документация и порог вхождения. (комментарий)

Баг был в systemd или нет?

Было несколько взаимосвязанных багов. Часть в systemd, часть в ядре.

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

Я в итоге забил на это дело, всё равно проявляется в 1 из 10 случаев, а в журнале (который в дебиане ещё и одноразовый по умолчанию) пусто.

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

Угу, «решение». Решение уровня /lor/.

И кучи других ресурсов. А что им всем остаётся, из других вариантов:

  • попытаться попросить переоткрыть баг и надеяться, что с ним помогут разобраться;
  • забить.

кто-то не реагирует на SIGTERM.

Знать бы кто этот кто.

Не он действительно не всегда появляется и не во всех (может зависит от версии systemd) дистрибутивах.

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

У Gentoo порог вхождения был выше и сам процесс установки та ещё нудятина.

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

Да, конфигурацию ядра для нового компа каждый раз делать очень лень.

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

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

Нашёл такое решение:

comm -23 <(pacman -Qqett | sort) <(pacman -Qqg base -g base-devel | sort | uniq)
grem ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.