Как Linux использует часы реального времени?
Вы могли бы сделать
sed 's/\(|[^| ]*\) */\1\&/4;s//\1\&/2'
для вашего примера. Объяснение:
|[^| ]*ищет ваш разделитель полей и все не -пробелы в этом столбце. Он сгруппирован с \(\), поэтому позже его можно скопировать с заменой на \1. Затем один или несколько пробелов будут заменены &, которые необходимо экранировать в строке замены. 4означает применить это к четвертому вхождению, которое является пятой колонкой. Затем повторите это с 2для третьего столбца. Вам не нужно повторять шаблон, давая пустой шаблон.
Более сложно, если в столбце может быть более одной группы пробелов или их может не быть вовсе. Тогда лучше используйте другой инструмент, например awk.
С другой стороны, если вы знаете, что в каждом столбце всегда есть один пробел, выполните простой
sed 's/ /\&/5;s//\&/3'
Большое спасибо sourcejedi за этот ответ . Это действительно привело меня к правильному ответу.
Ответ на вопрос
How does Linux use a real time clock to maintain the system clock?
Это происходит только один раз, во время загрузки. Он не будет снова запрашивать RTC до следующей перезагрузки. Это настраивается, но будет сделано по умолчанию в большинстве сборок ядра.
I want to know if an error with the real time clock would only present itself in the system clock when a timesync agent (ntpd or systemd-timesyncd) updates.
Если система не будет перезагружена, маловероятно, что время в RTC вообще попадет в системные часы. Некоторые агенты, такие как ntpd, могут быть настроены на использование RTC в качестве источника времени , но обычно это не включено по умолчанию. Не рекомендуется включать его, если вы не знаете, что RTC — очень хороший источник времени.
Is there any direct link between the system clock?
Похоже, время копируется в другую сторону. RTC периодически обновляется системным временем. Согласно ответу sourcejedi, это делается ядром, если установлено CONFIG _RTC _HCTOSYS .
Это можно проверить:
Установите часы реального времени
# hwclock --set --date='18:28'Затем проверяйте время RTC каждые несколько минут с помощью :
.# hwclock
Результатом этого будет то, что системное время вообще не изменится, и RTC в конечном итоге вернется к системному времени.
Причина скачков времени на ГЭБ
Как указал sourcejedi, сообщения инициировались не systemd-timesyncd. Они были вызваны connman.Доказательством было(должно быть)ложное сообщение журнала в/var/log/syslog:
Oct 3 00:10:37 hostname connmand[1040]: ntp: adjust (jump): -27302612.028018 sec
...
Nov 21 00:07:05 hostname systemd[1]: Time has been changed
до версии 1.37 connman жестко запрограммирован для беспорядочного опроса шлюза по умолчанию на время. Для этого не нужно настраивать DHCP, и если NTP-клиент connman включен (, он по умолчанию ), тогда он будет делать это независимо от любой другой конфигурации.
В нашем случае некоторые домашние маршрутизаторы действительно отвечали на эти запросы NTP, но результаты были крайне ненадежными. В частности, когда маршрутизатор был перезагружен, он продолжал выдавать время, фактически не зная точного времени .
Например, мы знаем, что по крайней мере одна версия BT Home Hub 5 при перезагрузке будет по умолчанию установлена на 21 ноября 2018 года и выдаст эту дату по NTP. Затем его собственный NTP-клиент исправит проблему, но есть окно, в котором он раздает 21 ноября 2018 года.
То есть, эта проблема в конечном итоге была вызвана тем, что наши клиенты перезагрузили свой маршрутизатор, а мошенник просто согласился на этот раз.
Я выражу здесь свое разочарование, кажется, воинственность некоторых оставила эту «черту» в аферистах слишком долго. Об этом сообщалось как о проблеме еще в 2015 году . И это действительно хорошо скрытая «фича». Нет настроенных серверов времени и сообщений в журнале, объясняющих, что делает мошенник, или документации о том, почему. Если ваши тестовые установки не имеют NTP-сервера на шлюзе по умолчанию, вы никогда не увидите этого при тестировании.
Как исправить
Мы рассматриваем два варианта, оба из которых работают:
Полностью удалить connman. Кажется, что сеть прекрасно работает и без него; мы еще не нашли причину его появления.
apt-get remove connmanОтключите NTP в connman, отредактировав
/var/lib/connman, добавив:[global] TimeUpdates=manual
man rtc есть хорошее введение:RTC против системных часов . После объяснения того, что «настенные» часы RTC работают от батареи и тикают, в то время как системное время отсутствует -не существует (питание выключено/спящий режим и т. д. ), он говорит:
... So at boot time, and after resuming from a system low power state, the system clock will often be set to the current wall clock time using an RTC.
Это не имеет никакого отношения ни к каким агентам, это то, что каждый пользователь ожидает от своего ПК на протяжении десятилетий, будь то Windows или Linux. Так что да, есть очень прямая связь между RTC и системными часами.
"случайные скачки системных часов на несколько месяцев"
...это было исправлено (, так что до )это было совершенно неправильно?
...или было правильно, а тут вдруг (перезагрузка? )прыгнули в прошлое? в будущем?
Линукс? Для «сервера» вам нужен NTP. systemd -timesyncd является типичной промежуточной вещью, согласно справочной странице :может помочь вам, если у вас вообще нет RTC и есть эта «минималистичная» служба SNTP.
rtc_cmos rtc_cmos: setting system clock to 2019-10-27T07:38:03 UTC (1572161883)
Это происходит во время загрузки ядра непосредственно перед запуском initrd --, если это неправильно (ненадежный RTC ), тогда какая-то служба NTP может отменить или даже исправить (в случае RTC надежен, но немного медленный или быстрый ).
Не знаю, как подвести итог всем этим совершенно бесплодным комментариям...
Прошиваю -проверил ссылку BBB -; 50$ за материнскую плату. RTC не работает должным образом, и теперь все эти комментарии? Нет информации?