Лёня продолжает развлекаться

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

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

время скорректируется до чуть более разумного

До какого?

Где ты усмотрел ожидание хоть чего-нибудь?

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

Это зачем?

Леннарт пытается нас спасти, очевидно же. И неважно, что его никто не просил.

А если обновляться раз в год? Или там в исходниках таймстамп захардкожен?

( grem)

Или там в исходниках таймстамп захардкожен?

Именно.

https://github.com/systemd/systemd/commit/021dd87bc055a5bfb2dcef83fc868fe2464...

For use in timesyncd we already defined a compile-time «epoch» value, which is based on the mtime of the NEWS file, <...>

Ты знаешь, что такое UTC?

Затем что в BIOS должно быть время в UTC.

Что за чёрточка перед /bin/sh?

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

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

Не должно.

Гентушник, а не знаешь, что время сборки/релиза можно захардкодить

Ещё скажи, что гентушники исходники перед установкой пакета должны просматривать.

Всё равно пока непонятно «зачем», если и так есть отдельная служба синхронизации времени.

Учитывая, что Лёня добавил ещё и поддержку DNSSEC в resolved, всё как раз таки сходится. ЕМНИП, там точно так же важно время.

Если время на системе обнулится, то проверить подлинность присланного тебе ответа DNS не представляется возможным. А значит ntp-демон(в том числе тот же timesyncd) не сможет из домена получить IP-адрес, а значит не сможет соединиться и получить текущее время.

А если по SSL во время загрузки соединяется что-то ещё, оно тоже зафейлится по цепочке.

А ARM-платки, без батареек, так вообще получается не смогут пользоваться DNSSEC.

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

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

Не должно.

Вендузятнег детектед.

Это очередное феерическое изобретение по расширению синтаксиса юнитов.

If the absolute filename is prefixed with "-", an exit code of the command normally considered a failure (i.e. non-zero exit status or abnormal exit due to signal) is ignored and considered success

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

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

Ну да, опцию а-ля «localtime» специально по моей просьбе добавили. А у любого Ъ на наручных часах время в UTC должно быть выставлено, иначе пацаны не поймут.

А ssh почему не работает?

А, всё, про VPN прочитал.

Чую задницей, тут дело в кавычках.

Леннарт

Вот это поворот, четыре года был поцеринг, а тут нате. Это же никак не связано с посвящением в каменщики?

Леннарт

Вот это поворот, четыре года был поцеринг

Где поворот? Леннарт Поцеринг.

Интересно, а systemd учитывает часовые пояса когда время выставляет.

Учитывая, что в норме оно часовыми поясами и заведует, думаю, да. А разве сертификаты их учитывают? Мне как-то казалось, что в таких местах везде UTC.

Ну да, опцию а-ля «localtime» специально по моей просьбе добавили.

Deprecated.

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

При чём тут наручные часы, чудовище?

Deprecated

Где? Когда? о_О Опять всё пропустил

то есть я про «UTC=no»

Где? Когда? о_О Опять всё пропустил

https://wiki.archlinux.org/index.php/Time#Time_standard

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

UTC is also known as GMT

вот это совсем не одно и то же

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

Глазки разуйте. Там приведён ряд причин, по которым localtime в биосе не рекомендовано.

вот это совсем не одно и то же

Though conceptually different,

приведён ряд причин, по которым localtime в биосе не рекомендовано

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

Though conceptually different

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

тут дело в кавычках.

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

deprecated

//fixed

И логов тоже нет. Плохо.

Из этого никак не следует, что он depricated.

«Deprecated» означает «нерекомендуемый». Так что следует.

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

Конечно, не обязан. Просто потом не жалуйтесь, если что, вас предупреждали.

it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems

local у меня установлен именно для избежания таких конфликтов

Просто потом не жалуйтесь, если что, вас предупреждали.

если они целенаправленно что-то не поломают связанное с этим, то жаловаться не буду

«Deprecated» означает «нерекомендуемый».

Не совсем так.

local у меня установлен именно для избежания таких конфликтов

А потом каждая ОС заботливо переводит время на летнее, ага.

Не совсем так.

Словарик откройте.

А потом каждая ОС заботливо переводит время на летнее

сейчас нет перевода на летнее время, а когда переводили, то никаких конфликтов из-за этого не было

Словарик откройте

я и не открывая могу сказать, что это не точные синонимы, тем более, что там нет фразы «not recommended» в отношении «localtime», а значение «deprecated» заметно шире просто «нерекомендуемый».

сейчас нет перевода на летнее время, а когда переводили, то никаких конфликтов из-за этого не было

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

тем более, что там нет фразы «not recommended» в отношении «localtime»

it is strongly recommended to set the hardware clock to [not localtime]

Совсем нет, ага.

Совсем нет, ага

именно так

На оборот, хорошо, так как системд капец становится всё ближе и ближе.

скорее, земля разверзнется и поглотит ирода.

Пфф... Вырвал фразу из контекста, и считаешь, что хорошо набросил?

local у меня установлен именно для избежания таких конфликтов

В той же статье на арчевики рассказано как переключить винду на использование UTC одним ключиком реестра. В других дистрибутивах Linux кроме какой-нибудь дикой маргинальщины UTC по дефолту. В MacOS аналогичная ситуация (и вполне возможно её даже нельзя переключить на localtime). При этом использование UTC гарантирует отсутствие глюков типа «изменились настройки часовых поясов (летнее/зимнее время, законодательное изменение принадлежности региона часовому поясу, переезд машины и т. п.) - каждая ОС провела независимую коррекцию и время улетело чёрт знает куда». Так что выбор очевиден. А у тебя просто синдром утёнка.

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

Если кто-нибудь из знакомых просит поставить Linux рядом с виндой, всегда в последней перевожу часы в UTC (для этого у меня есть специальный reg-файл, по которому достаточно дважды кликнуть). Проблемы были с чем-угодно, только не с часами.

А у тебя просто синдром утёнка.

А у вас двоих батхерт, чего уж там.

Да пусть даже и синдром утёнка, не вижу причин дёргаться из-за данной настройки, с которой всё было понятно 12 лет назад и подстраиваться под чьё-то мнение. В этой же статье пишут, что для XP не рекомендуют такое переключение, которая и была в то время. Больше удивляет возмущение уже 2 человек, что кто-то использует localtime, просто потому, что ему так удобнее.

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

Я понял так, true_admin жаловался на то, что отладка юнита у него заняла столько сил и времени, что не смотря на её ушпешное завершение о решил с дальнейшим решением задачи не связываться( не стал включать одноплатник.)
А вы ещё и добавляете «И логов нет».
Ну и как это для инициатора системы понимать как либо иначе, как форменное безобразие?
Системд капец в полном виде.

Я посетовал на то, что тот логов не сохранил. Пусть они для него и выглядели бредом, но они могли помочь.

Леннарт пытается нас спасти, очевидно же. И неважно, что его никто не просил.

А если не согласен спасаться, то ты - хейтер и ренегат.