В федорке проснулись

Ничего не понял, но согласен что федорка это кал

То, что по ссылке, и когда systemd ждёт какой-то юнит не 2 минуты, а просто неограниченно - это одно и то же? Тогда молодцы, чо. Хоть кто-то озадачился.

Неужели, кто-то заметил? Я думал, просто лыжи не едут.

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

Ну как не приходит - у федоровцев два года баг висит, периодически ходят с челобитными в апстрим.

дебиане

this

Я всё ждал, пока не найду объяснения в интернете. Специально не искал. Списывал на то, что сам тупой.

Так в чём баг-то? В том, что по умолчанию ожидается завершение сервисов в течение 2 минут? Серьёзно?

А то что systemd стопорит загрузку и вылетает в emergency shell, если не может примонтировать любой накопитель - это не смущает? 😁

Да. Нахрена такой гигантский таймаут?

А то что systemd стопорит загрузку и вылетает в emergency shell, если не может примонтировать любой накопитель - это не смущает? 😁

Любой, или всё же тот, у которого не указана опция nofail?

Да. Нахрена такой гигантский таймаут?

System V init had no timeouts at all, so the systemd developers chose ‘a conservative (i.e. overly long) value to not upset things too badly’, though there were still some who were unhappy that there were timeouts. He is in favor of the change: ‘lowering the time-outs by default would make sense to me, but of course, people will be upset’.

Да. Нахрена такой гигантский таймаут?

Потому что сервисы могут завершаться долго? Транзакции там в базе, виртуалки выключаться — да много что. 15 секунд по умолчанию слишком мало.

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

people will be upset

Инфа из его личных солевых приходов?

«О нет, компьютер слишком быстро выключается/перезагружается!» - расстроился ни один человек в мире.

Транзакции там в базе, виртуалки выключаться

А, я и забыл, что Линукс это поделка для серверов, которая на десктопах присутствует в формате «вот тебе отбросы, жри чё дали»

Потому что сервисы могут завершаться долго? Транзакции там в базе, виртуалки выключаться — да много что. 15 секунд по умолчанию слишком мало.

Разумно, но всегда можно прописать долгий таймаут в юнит-файлах там, где он на самом деле нужен.

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

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

Я б сказал, линукс не для слабых умом.

У меня на sddm 10 сек таймаут стоит.

Разумно, но всегда можно прописать долгий таймаут в юнит-файлах там, где он на самом деле нужен.

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

И это всё потому, что у кого-то нет терпения минуту подождать. Бред.

Если кто-то админит сервера и не следит за подобными новостями - ССЗБ.

На десктопе вообще нужно так: пользователь нажал «Выключить» или «Перезагрузить» - через секунду все процессы уже убиты.

Секунда это тыща лет для компьютера, какого чёрта вообще

С исчезновением противоречий между постоянной и оперативной памятью - запросто. А так - кто и как скинет все твои котики на диск и справится за секунду?

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

…А учитывая, что такие задержки возникают лишь в случаях зависания сервисов, когда те не реагируют на сигналы завершения — чинить тогда надо эти сервисы, не? Кто знает, какие данные в них могут теряться из-за принудительного жёсткого пристреливания.

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

Именно наличием кривых сервисов и оправдывали свое бездействие в этом плане разработчики systemd, полагая, что со временем подобные косяки в сервисах будут устранены. Эксперимент, очевидно, неудачен.

Если кто-то админит сервера и не следит за подобными новостями - ССЗБ.

Ну да, давайте завтра ещё какое-нибудь поведение сломаем — все ж читают новости и обязательно заметят.

omae wa mou если новое поведение рушит твой демон - значит, он уже сломан.

А что мешает этим индивидуумам выставить любой устраивающий их таймаут по умолчанию в конфиге? Сложно одну строчку поменять? Надо обязательно распространять потенциально ломающие изменения на вообще всех?

кто и как скинет все твои котики на диск

В эпоху SSD таймауты нужно сокращать, это первое. Да и вообще с вытеснением медленных магнитных блинов смысл кэширования сходит на нет.

Второе: пользовательские данные должны сохраняться постоянно и в первую очередь. А если пользователь жмёт «Сохранить» - данные должны именно что сохраниться, а не сделать вид, что сохранились, продолжая висеть в оперативке.

Посему, когда пользователь сохранил свои данные и нажал «Перезагрузка» - его данные уже должны быть на накопителе. А если системе нужно пять минут копаться и сохранять своё драгоценное непонятно что - очевидно, что система охренела и позволяет себе слишком много. Так делать не нужно.

Специально для тех, кто не приемлет никаких изменений вообще, есть прекрасная опция «не обновляться». По умолчанию.

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

Специально для тех, кто не приемлет никаких изменений вообще, есть прекрасная опция «не обновляться». По умолчанию.

Передёргиваете. Речь шла о потенциально ломающих изменениях, а не изменениях вообще.

Причём причина этих изменений вообще не поддаётся цензурному описанию.

Потенциально ломающие изменения происходят на границе релиза, проходят специальный процесс утверждения, анонсируют я в release notes и в медиа. Как это. Но ты же все ещё ворчишь.

Я как-то здесь предложил это решение и мне ответили, что-то вроде «решение достойное локалхоста». Вариантов правильного решения, разумеется, не предложили.

Самому багу много лет и он считается пофикшенным апстримом (да, но пока нет). Инструкций, как выяснить, что или какой сервис приводит к подобной задержке и при каких обстоятельствах мне не попадалось.

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

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

Во-первых, в процессе завершения работы выводится соотв. сообщение, а ля «Stopping <сервис> (10s / 1m 30s)».

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

Есть и экзотические методы вроде запуска debug-shell.service и выполнения там чего-то типа systemctl list-jobs, но в подавляющем большинстве случаев пары выше достаточно.

Потенциально ломающие изменения происходят на границе релиза, проходят специальный процесс утверждения, анонсируют я в release notes и в медиа. Как это. Но ты же все ещё ворчишь.

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

Нажимай ресет, будь мужиком блеат!

Я так и делаю, когда systemd тупить начинает

Тогда странно, что при столь очевидном решении и процессе отладки никто толком не смог решить проблему.

Нет, никаких полезных сообщений о том, что завершается так долго тогда не было. Может сейчас есть?

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

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

уже месяц

Если бы.

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

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

Месяц и четыре дня, раз ты так настаиваешь на точности.

Месяц и четыре дня ты спал, а потом разродился тредом с заголовком «в федорке проснулись».

Тогда странно, что при столь очевидном решении и процессе отладки никто толком не смог решить проблему.

Возможно, проблема проявлялась у тех, кто не мог её решить в силу отсутствия нужных знаний? Это ведь не повсеместное явление.

… которое должно происходить каким образом? Фея на единороге прискачет и пофиксит? Или может давайте удалять RPM пакет с глючным юнитом и не давать поставить его обратно, пока пользователь не напишет баггрепорт?

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

Ага это то самое, в результате чего пользователь видит сообщение?

stop job is running for session of user 

Очень полезно, но что это значит? Почему?

Вот, развлекайся: https://bugs.freedesktop.org/show_bug.cgi?id=70593

Видишь, апстрим уверен, что пофикшено, но не знает когда и как. Но баг почему-то актуален до сих пор.

Алё, по поводу этого поведения ноют примерно с момента введения таймаутов - а это было на заре становления systemd. В самой федорке джва года диспутируют её разработчики.

… которое должно происходить каким образом? Фея на единороге прискачет и пофиксит? Или может давайте удалять RPM пакет с глючным юнитом и не давать поставить его обратно, пока пользователь не напишет баггрепорт?

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

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

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

«Зависает сервис? — а давайте тупо уменьшим таймаут, чтобы проблема глаза не мозолила, и тогда можно сделать вид, что проблемы-то и нет!»

Очень полезно, но что это значит? Почему?

Это значит, что пользовательский экземпляр systemd не завершается из-за какого-то пользовательского процесса, игнорирующего SIGTERM.

Да, в данном случае было бы правильно выводить имя соотв. пользовательского сервиса/процесса. И именно это было бы хорошим решением, а не уменьшение таймаута.

Что же за процесс так завис, на данный момент можно узнать в журнале.

Добавлено: Нашёл пример у человека, у которого была такая проблема:

Jan 11 16:22:14 ArchBTW systemd[764]: plasma-kwin_x11.service: State 'stop-sigterm' timed out. Killing.

а давайте тупо уменьшим таймаут, чтобы проблема глаза не мозолила

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

Или в консольке с бесконечным таймером кнопку какую запилить со смыслом «да, я ХОЧУ небезопасно прибить всё это и выключить уже комп наконец». Пусть хотя бы прибьёт мешающие процессы, но таки даст железу потушиться нормально, а не проводом из розетки.

И именно это было бы хорошим решением, а не уменьшение таймаута.

Nyet. Вывод инфы ПЛЮС таймаут и не трепал бы нервы, и позволил разобраться, если очень чешется. А без таймаута у нас снова два стула Reset или провод из розетки.

В десктопных дистрах это было бы поведение «по пути наименьшего идиотизма и минимизации суходрочки».

Если разработчики дистрибутива хотят, то им вообще ничто не мешает уменьшить этот таймаут хоть до 1 секунды, указав новое значение в /etc/systemd/system.conf:

DefaultTimeoutStopSec=<число>

Точно так же это могут сделать и все остальные, кому ждать полторы минуты невмоготу.

(Причём я не против разумного пересмотра значения по умолчанию, если новое будет аргументировано и обосновано. Но 15 секунд по умолчанию для всех — это явный перебор.)