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

Вы сейчас опять про что-то другое?

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

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

Пользователь никак не ожидает, что компьютер будет выключаться 90 секунд.
На дворе 2023 год если что.
Даже 15 секунд не так уж мало.
Особенно учитывая SSD.

Да, в инде эта тема сделана правильно. А в линупсах две крайности, и обе на букву Хэ.

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

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

ТС ничего не сделал для Ъ, не уважение к ЛОРу :-)

У меня федорки всегда включались, выключались, перезагружались быстро, и сейчас альма стартует несколько секунд и выключается за секунду наверное (может преувеличиваю, но по ощущениям так). Надо вырубать ненужные сервисы, а нужные, но глючные, уже подкручивать, если возможно (обычно что-то сделать можно так или иначе).

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

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

Долгое выключение линукса в казалось бы нормальных условиях отличается от случая установки обновлений на винде (притом винда-то и над этим недостатком провела серьёзную работу и теперь этот процесс намного проще и быстрее — ещё в 1913 году великий писатель Сунь Вынь призывал к тому чтобы проявлять уважение к «врагу»).

:D

Как и ожидалось.

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

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

Страус_с_головой_в_песке.png

Ну хорошо хоть не где-то ещё.

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

https://codybonney.com/change-default-timeouts-starting-stopping-systemd-units/

Тебе уже всё сделали. Можешь включить, разрешаю.

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

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

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

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

Вы просто не сталкивались с такими. Например, Z-отчёт с закрытием смены у некоторых терминалов может до 15 минут идти (привет, INPAS). У нас есть сервисы, которые ожидают завершения всех подключений (== операций клиентов) прежде чем выйти, и у них самые разные таймауты соединения: от 5 до 60 секунд ЕМНИП.

Разумеется, для сервисов, которые корректно завершаются дольше 15 секунд, можно прописать свой собственный таймаут. Однако у многих таких сервисов своё значение просто не указано, ибо дефолтное устраивало. И такие сервисы запросто могут сломаться от таких изменений. Если бы 15 секунд стояло изначально, то вопросов не было бы, но рассматривать значение в вакууме, в отрыве от уже существующей инфраструктуры, использующей предыдущее значение, неразумно. Нужно балансировать потенциальные выгоды от таких изменений с возможными рисками от них.

И хрен бы с ним, если бы были серьёзные обоснования для такого изменения, но «мне лень ждать полторы минуты» — серьёзно?! А в этой теме сюда ещё и не относящиеся к предмету бесконечные ожидания приплетают зачем-то — как будто у людей появилась надежда, что это изменение «исправит» их проблемы (спойлер: не исправит)…

Мне абсолютно понятно, почему для Fedora Server сделано исключение. Главное чтобы в upstream какое-нибудь неадекватно маленькое значение для вообще всех не пропихнули.

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

systemd — это менеджер системы (и система инициализации), ориентированный преимущественно на серверы, а не десктопы. (Только до systemd на десктопах был ещё больший серверный ужас — sysV).

На десктопе такой комбайн не требуется, а больше подходит легковесная, быстрая, модульная и легко конфигурирующаяся система инициализации. Например, 66-init (suite66), основанная на s6 и использующая унифицированные службы, а не дистроспецифичные shell-портянки. (66 может использовать в качестве PID 1 не только s6, а любую другую систему инициализации: SysV, runit, etc.)

Вы просто не сталкивались с такими. Например, Z-отчёт с закрытием смены у некоторых терминалов может до 15 минут идти (привет, INPAS).

Ну так это уже не будет работать с дефолтным таймаутом. Предлагаешь везде 15 минут прописать?

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

Ну и хер с ними?

И хрен бы с ним, если бы были серьёзные обоснования для такого изменения, но «мне лень ждать полторы минуты» — серьёзно?!

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

Ну так это уже не будет работать с дефолтным таймаутом. Предлагаешь везде 15 минут прописать?

Нет, не предлагаю. Конкретно этот сервис не вписывался в дефолтный таймаут, поэтому для него он был прописан отдельно. А вот второй пример вписывается, поэтому там таймаут не прописан. И таких примеров наверняка полным-полно.

Ну и хер с ними?

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

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

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

Согласен с вашей формулировкой, но вот вопрос: а зачем постоянно ребутать?
Пробежал по своим:
1. Десктоп1 - 51 день.
2. Поддиванный, он же десктоп2 - 8 дней (уже не помню зачем я его в ребут отправлял)
3. Ноут - 49 дней
4. Рабочий десктоп - 2 дня ( ребутнулся не моими усилиями, видимо что-то с питаловом было)

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

Домашним пользакам заходит, да и «около домашним»(если какой-то спец софт не нужен) тоже.

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

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

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

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

Вы намекаете на вариант описанный выше с транзакцией в БД? В смысле «и куда у нас делись данные которые мы вроде как закомитили»?

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

Шикарная формулировка!

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

Вы намекаете на то, что сюрприз админы получат по прошествии времени?

Возможность вручную ускорить завершение работы каким-нибудь Ctrl+C, если точно известно, что это не навредит, была бы полезна.

Очень годное предложение!

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

Та фиг с ним с выключением, хуже с включением, есть у меня прямо сейчас один пользователь мозготрах на тему «почему у меня thunderbird так долго стартует?» «долго» это меньше 3-х минут, хранилище over 200Гб, машинка iMac 15-го года, я вот реально незнаю уже, что ещё можно сделать. Чел хочет, что бы у него за 20сек стартовало и ниимеет. :(

Давай честно: если сервис не завершился за 15 секунд, скорее всего он не завершится вообще и его надо прибить.

Та ладно

Shutting down Squid in 30 seconds:  ............

Только до systemd на десктопах был ещё больший серверный ужас — sysV

Живу с этим ужасом, брат жив, чяднт?

Если я хочу быстро перезагрузить компьютер

reset на системнике

Я намекаю, что для десктопного профиля можно тайм-аут и поменьше для дефолта сделать. А пропали данные из транзакции через 15 секунд или через 90 уже не так важно. Важно что они пропали.

Жалобы на долгое выключение не от админов с базами наверняка.

Или все уверены, что через 90 секунд ещё одна проверка будет, что всё успешно завершилось, и предложат подождать ещё?

Я намекаю, что для десктопного профиля можно тайм-аут и поменьше для дефолта сделать.
десктопного профиля

А это что такое за зверь?

А пропали данные из транзакции через 15 секунд или через 90 уже не так важно.

Через 90сек вероятность пропажи меньше.

у меня openrc и таких проблем у меня нет :D

Ну у меня какбэ тоже не ненужнод, ибо православный дистр. :) Но на мой вопрос ви таки не ответили, печалька...

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

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

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

Понял. Спасибо за пояснение.

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

Ну собстно я о чем и написал.

Согласен с вашей формулировкой, но вот вопрос: а зачем постоянно ребутать?

Аудиторы. Специально ищут системы, где обновление ядра прилетело, а перезагрузки не было. И еще изучают логи. А потом, если найдут систему, на которой перезагрузку после обновления безопасности ядра отложили более чем на 14 дней, тыкают в Cyber Essentials и говорят, что нарушены условия сертификации.

Ребут после обновы ведра это понятно, но я задал вопрос «зачем постоянно ребутать?»

Ок, давайте заведём правило «не больше трёх раз» в день (иначе это будет «играешь с ним»).

иначе это будет «играешь с ним»

Душевно :)

Ну вот, теперь может исправят.

Думаете прогнутся?

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

Думаете, оставят дохнуть грязно?

Думаю да.

Для этого есть таймауты для конкретного юнита. В таковом для Sqiud должен быть прописан таймаут с учётом реального времени его завершения.

А я думаю, что в дистре поправят, а в апстриме хотя бы подумают над своим поведением.

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

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

Ребут после обновы ведра это понятно, но я задал вопрос «зачем постоянно ребутать?»

А вы посмотрите, как часто эти обновы прилетают, особенно для «облачных» ядер (aws, gcp) в Ubuntu. И поскольку известно, что сборщики тихо скрывают исправления безопасности в обычных обновлениях, приходится делать ребут после каждого прилетевшего обновления ядра. Т.е. по сути раз в две недели, если строго по требованиям сертификации.

💡 Например, в винде уже как 30 лет этот вопрос решён: службы имеют возможность сообщить менеджеру служб, что они нормально работают - через специальный колбэк, включая процесс запуска и останова. Если колбэк не дёргать, то менеджер прибивает службу по умолчанию через 20 секунд (можно задать в реестре).