LINUX.ORG.RU
ФорумTalks

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

 


0

0

Из чейнджлога systemd 229:

В процессе загрузки PID 1 теперь проверяет системное время и корректирует его, если установлено время, предшествующее времени выпуска используемого релиза systemd;

http://www.opennet.ru/opennews/art.shtml?num=43862
https://lists.freedesktop.org/archives/systemd-devel/2016-February/035748.html

Это что за прикол? Это зачем?

★★★★★
Ответ на: комментарий от Axon

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

Black_Shadow ★★★★★
()
Последнее исправление: Black_Shadow (всего исправлений: 2)
Ответ на: комментарий от grem

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

intelfx ★★★★★
()
Ответ на: комментарий от intelfx

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

До какого?

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

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

grem ★★★★★
()
Ответ на: комментарий от grem

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

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

nexfwall ★★★★
()
Последнее исправление: nexfwall (всего исправлений: 1)
Ответ на: комментарий от nexfwall

Не должно.

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

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

grem ★★★★★
()
Ответ на: комментарий от grem

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

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

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

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

nexfwall ★★★★
()
Последнее исправление: nexfwall (всего исправлений: 2)
Ответ на: комментарий от Black_Shadow

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

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

Axon ★★★★★
()
Ответ на: комментарий от nexfwall

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

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 не ругался. Иначе прикинь что будет если от этого юнита зависит какой-нить важный таргет.

true_admin ★★★★★
()
Ответ на: комментарий от Axon

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

true_admin ★★★★★
()
Ответ на: комментарий от Axon

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

grem ★★★★★
()
Ответ на: комментарий от tailgunner

Леннарт

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

d_a ★★★★★
()
Ответ на: комментарий от d_a

Леннарт

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

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

tailgunner ★★★★★
()
Ответ на: комментарий от true_admin

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

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

Axon ★★★★★
()
Ответ на: комментарий от grem

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

Deprecated.

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

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

Axon ★★★★★
()
Ответ на: комментарий от Axon

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

UTC is also known as GMT

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

grem ★★★★★
()
Ответ на: комментарий от grem

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

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

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

Though conceptually different,

Axon ★★★★★
()
Последнее исправление: Axon (всего исправлений: 1)
Ответ на: комментарий от Axon

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

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

Though conceptually different

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

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от nexfwall

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

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

true_admin ★★★★★
()
Ответ на: комментарий от grem

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

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

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

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

Axon ★★★★★
()
Ответ на: комментарий от Axon

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

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

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

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

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

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

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 1)
Ответ на: комментарий от grem

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

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

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

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

Axon ★★★★★
()
Ответ на: комментарий от Axon

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

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

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

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

grem ★★★★★
()
Ответ на: комментарий от grem

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

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

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

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

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

Axon ★★★★★
()
Ответ на: комментарий от ass

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

Iron_Bug ★★★★★
()
Ответ на: комментарий от grem

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

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

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

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

KivApple ★★★★★
()
Последнее исправление: KivApple (всего исправлений: 6)
Ответ на: комментарий от KivApple

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

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

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

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

grem ★★★★★
()
Последнее исправление: grem (всего исправлений: 3)
Ответ на: комментарий от nexfwall

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

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

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

nexfwall ★★★★
()
Ответ на: комментарий от tailgunner

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

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

rupert ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.