А они не хотят. Я могу понять этот подход на сервере, где надо гигабайты на диск скидывать и прочее, чтобы не побилась какая-нибудь Очень Важная База. На десктопе это зачем? Иксы уже в любом случае прибиты, вся гуйня прибита, оно встаёт враскоряку на чём-то системном.
ждать полторы минуты
В том-то и дело, что этот таймер крутится бесконечно. Я ждал до полутора часов, это ничего не поменяло. Полторы минуты - не вопрос, хотя опять же на десктопе откровенный перебор.
В том-то и дело, что этот таймер крутится бесконечно. Я ждал до полутора часов, это ничего не поменяло
Тогда это не имеет ровным счётом никакого отношения к обсуждаемой теме. Здесь лишь предлагается уменьшить значение по умолчанию, которое сейчас составляет 1 мин 30 с.
А так, сервисы могут выставить для себя другие значения таймаутов, в том числе очень большие. Скажем, для какого-нибудь unattended-upgrades это будет хорошей идеей.
Сделать это удобным. У меня есть проблема, симптомы такие, вот вам /var/log/* - чем смог помог. А собирать-ставить отладочные версии софта и далее по нарастающей - да ну его нах, тогда уж лучше таймаут с SIGKILL или кнопку для ускорения процесса.
Я изначально имел в виду, тупо принимать баг и его копать на основании легкодоставаемых логов. Хотя ваши варианты тоже хорошие, запилили же в systemd куар-коды ошибок.
На десктопе вообще нужно так: пользователь нажал «Выключить» или «Перезагрузить» - через секунду все процессы уже убиты.
Как что-то плохое. Я _уже_ отдал команду на выключение, значит я готов в потере несохранённых данных. Ну кубит при следующей загрузке какие-то хэши пересчитает, ну браузер ругнётся про восстановление сессии. Это не проблема.
Если человек выключает систему сидя на UPS без электричества? И да там в обсуждении приводился кейс когда таймаут проходит и просто удваивается. Может система пусть всё таки следует своим же таймаутам без этой шизы.
Потому что сервисы могут завершаться долго? Транзакции там в базе, виртуалки выключаться — да много что. 15 секунд по умолчанию слишком мало.
У меня с этим чаще всего висит не postgres с базами и не виртуалки, а какой-нибудь upower или udisks. Нахрена они висят? А хер их знает! Это ж глючный лялекс, в нём всегда какие-то баги.
Багу почти 10 лет. Да, выводить правильно было бы, но не выводидось. Это на свежеустановленных системах, без ковыряния пользователем сервисов. И не только в Fedora и в основном далеко не в kde-plasma. И что делать с этим сервисом?
A concrete reason to wait longer was provided by «allan2016»: ««15 seconds will for sure kill the modem on the Pinephones for good.»» Removing the power without waiting the 20-30 seconds its modem needs to shut down will apparently brick the modem.
Ты раскрой «засунуть под ковёр», затем допетри, что пользователь != разработчик и ужесточение ситуации для разработчика ведёт к увеличению поломок и большему числу репортов, а там и щелкнет. А то пока только эмоционируешь, констатируешь одно и то же, ругаешь подход, не предлагая ни альтернатив, ни конструктива, и в целом не пишешь ничего полезного.
Есть сервисы, которые завершаются небыстро, особенно на каких-нибудь массивах из жёстких дисков да с параллельно завершающимися другими сервисами. Им такое резкое уменьшение таймаута может навредить.
Почему такая простая мысль до стольких людей не доходит?..
У меня с этим чаще всего висит не postgres с базами и не виртуалки, а какой-нибудь upower или udisks. Нахрена они висят? А хер их знает! Это ж глючный лялекс, в нём всегда какие-то баги.
И вы по этому поводу отправили отчёты об ошибках? Нет? Тогда сидите и ждите по полторы минуты – вы это заслужили.
И включаться по три часа, издавая кучу странных звуков как в фильме Чужой. А при выводе текста на экран каждый символ должен сопровождаться звуком печатного станка.
А оно на локальной машине не чинится нормально. Пускай пропихивают. Админы в конторах на своих серверах настроят потом как надо (да и вообще сервера так часто не выключаются, так что тут проблема скорее виртуальная).
А оно на локальной машине не чинится нормально.
Пускай пропихивают.
Вы умудряетесь самому себе противоречить в двух соседних предложениях. Если оно не чинится изменением таймаута по умолчанию на локальной машине, то не починится и изменением таймаута по умолчанию хоть в Fedora, хоть в upstream.
Было бы хорошо – здесь согласен. Возможность вручную ускорить завершение работы каким-нибудь Ctrl+C, если точно известно, что это не навредит, была бы полезна.
и всё же снизить таймаут
До какого значения? 15 секунд, т.е. ни много ни мало в 6 раз – на мой взгляд, перебор.
Очевидно, что это бага, которую использовали как психологический реппелент от возможных проблем. Внедрение неготового продукта уже являлось точкой когда у всех всё сломалось. То, что при этом сломалась бы ещё пара сервисов было неважно. При этом сейчас у таких сервисов были бы свои правильные таймауты. Всё остальное (что не хранит важных данных) прибивалось бы моментально.
И это всё потому, что у кого-то нет терпения минуту подождать. Бред.
Вот раздражает, когда ложишься спать, пишешь sudo poweroff, а оно потом ещё висит на завершении повисшего NetworkManager 2 минуты. Причем NM можно грохать без жалости в любое время, какие там данные потеряться могут? Вот и приходилось REIUS(без B) использовать. Хотя, я да, тоже 15сек поставил какое-то время назад.
…А потом ещё жалуются, откуда столько багов. А может, оттуда, что предпочитают подпереть костылём в виде маленького таймаута вместо того чтобы как ответственный пользователь собрать информацию, логи и отправить разработчикам?
Если юзер дал явную команду на выключение, она должна быть выполнена
Меньшее значение таймаута по умолчанию ровным счётом никак не повлияет на то, будет команда выполнена или нет. Если команда на выключение будет не выполнена, то это уже какой-то баг, не относящийся к данной теме.
Воркфлоу системы не должен становиться раком из-за непосланного багрепорта, это очевидная функциональность системы.
Скорее более низкий таймаут с большей вероятностью позволит выяснить причину задержки, чем такой длинный и приступить к починке сервиса в системе.
Как мне кажется, это недостаточно безопасное решение. Проблема сейчас в том, что в systemd таймаут для принудительного завершения юнита не отделен от таймаута для жалоб и диагностики. Более того, сама диагностика хромает - даже получить логи непосредственно перед выключением системы проблема, которую надо решать маленькими скриптиками.
Если цель - вычислить тормозов, то надо добавить в systemd код, который снимает core через 15 секунд, но не убивает процесс.