Здравствуйте! Добавил в сборку ntp client для получения времени от сервера. Написал свой ntp.conf файл.
Вот его содержимое:
server 10.22.82.155 iburst prefer
driftfile /var/lib/ntp/ntp.drift
logconfig=syncstatus+sysevents
logfile /var/log/ntp.log
Проводил эксперимент с синхронизацией времени от сервера, сетил в date отличное от текущего время и год, и смотрел пройдет ли синхронизация. Если отключить во встраиваемой системе демон, а потом заново его запустить, синхронизация времени происходит. Как только после запуска демона я вручную меняю время и жду синхронизации, происходит несколько запросов, время не подкручивается, а потом демон просто падает, минут через 20. Если вручную задать ntpdate -s 'server_addr', то синхронизация проходит, в случае если демон упал.
Если патчи для решения данной проблемы? Или нужно предоставить дополнительные данные?
насколько помню демон не меняет время "скачком" а подстраивает периодически маленькими шагами и максимальный шаг можно указать через конфиг - надо ман смотреть, может я путаю с сервером синхронизации времени
вот эта утилита и предназначена для разовой синхронизации "скачком"
На десктопе такой конфиг все подкручивал, причем разово, по этому сюда и задал вопрос. buildroot 2017
не знаю какой у вас десктоп и его конфиг - у меня в корневой buildroot скачком меняется время когда система стартует.
# date
Thu Jan 1 00:13:48 UTC 1970
# date
Thu Jan 1 00:13:52 UTC 1970
# date
Thu Jan 1 00:13:53 UTC 1970
# date
Wed Jan 29 14:30:09 UTC 2020
Если принудительно изменить год и число на работающей системе после синхронизации на неправильное - тогда нет.
# date -s 2019-01-01
Tue Jan 1 00:00:00 UTC 2019
# date
Tue Jan 1 00:00:11 UTC 2019
# date
Tue Jan 1 00:00:14 UTC 2019
# date
Tue Jan 1 00:00:17 UTC 2019
# date
Tue Jan 1 00:00:19 UTC 2019
# date
Tue Jan 1 00:00:59 UTC 2019
На десктопе такой конфиг все подкручивал, причем разово, по этому сюда и задал вопрос. buildroot 2017
не знаю какой у вас десктоп и его конфиг - у меня в корневой buildroot скачком меняется время когда система стартует.
# date
Thu Jan 1 00:13:48 UTC 1970
# date
Thu Jan 1 00:13:52 UTC 1970
# date
Thu Jan 1 00:13:53 UTC 1970
# date
Wed Jan 29 14:30:09 UTC 2020
Если принудительно изменить год и число на работающей системе после синхронизации на неправильное - тогда нет.
# date -s 2019-01-01
Tue Jan 1 00:00:00 UTC 2019
# date
Tue Jan 1 00:00:11 UTC 2019
# date
Tue Jan 1 00:00:14 UTC 2019
# date
Tue Jan 1 00:00:17 UTC 2019
# date
Tue Jan 1 00:00:19 UTC 2019
# date
Tue Jan 1 00:00:59 UTC 2019