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

Потому что таймаут такого завершения — по умолчанию 90 секунд. Ваш кэп.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Знаю, потому, что не сообщается о том, завершение какого процесса ожидается. То есть создаётся ощущение, что «ожидающему» самому неизвестно чего он ждёт. В баге 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.

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

Знаю

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

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

И не должно. Сообщается о том, завершение какого юнита ожидается. А завершение юнита — это опустошение цгруппы. Процессов там может быть 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’ов никому прилетать не должно.

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

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

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

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

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

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

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

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

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

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

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

Где?

«stop job is running for UNIT»

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

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

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

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

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

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

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

Гуляй, NEEDMOREINFO WORKSFORME WONTFIX.

«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 или нет?

«stop job is running for UNIT»

А если написано «A stop job is running for Session c2 of user Debian-gdm»?

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

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

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

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

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

Смотри выше.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

comm -23 <(pacman -Qqett | sort) <(pacman -Qqg base -g base-devel | sort | uniq)