Часы Linux теряют 10 минут каждую неделю
Я думаю, что Вы отсутствуете " со всех некоторых объектов на Ваших строках журнала и у Вас есть они вокруг других, которым не нужны они.
Попробовать
log_format main
'$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log logs/access.log main;
HyperV - это болезнь, NTPd - лекарство.
Где искать или что можно использовать для отслеживания изменения даты?
Вы можете запросить Демон NTPd (через клиент ntpq ) для получения разницы между локальными часами и эталонными часами серверов NTPd. Но это означает, что на самом деле запущен NTPd, поэтому вы не отслеживаете только свои изменения, вы отслеживаете комбинированный эффект ваших запущенных локальных часов и NTPd, синхронизирующего их.
На самом деле я не знаю, можете ли вы настроить NTPd для запуска (и дать вам вышеупомянутые показатели), но не для фактической настройки системных часов. Другой и менее эффективный способ - это периодически (cron?) Запускать ntpdate -q для набора эталонных серверов NTPd и контролировать его вывод, что даст вам разницу между вашими часами и эталоном, не касаясь локальных часов. Вывод будет таким:
$ ntpdate -q $YOUR_TLD.pool.ntp.org
[... list of queried servers ...]
17 Jul 12:14:11 ntpdate[42868]: adjust time server 109.168.106.59 offset -0.002517 sec
Вы можете отфильтровать последнее число и построить график, чтобы получить хорошее представление о том, сколько и когда ваши часы прыгают:
$ OFFSET=$( ntpdate -q $YOUR_TLD.pool.ntp.org | grep adjust | awk '{ print $10 }' )
$ echo $OFFSET
0.002970
In my tests I discovered that Hyper-V virtual machine clocks are very unreliable and frequently have a clock drift exceeding 500ppm. This is enough to cause even ntpd to fail. I had to switch to using chrony in these VMs to provide reasonably accurate wall clocks; it defaults to 1000ppm for this scenario and can be adjusted even further if necessary.
I no longer seriously consider Hyper-V for any application where timekeeping is especially important.
Дрейф часов в виртуальной машине Linux, работающей в Hyper-V, очень распространен , если у вас не установлены и не включены правильные компоненты интеграции . Hyper-V настроит аппаратные часы любой виртуальной машины, которую он запускает, но Linux по умолчанию не полагается на аппаратные часы после загрузки системы. Компоненты интеграции дают ядру подсказки о фактическом времени и устраняют эту проблему.
Если компоненты интеграции не подходят для вашего дистрибутива, то правильным решением является установка чего-то вроде ntpd и синхронизации с хостом Hyper-V или ваш местный пул часов.
The "problem" is that your running a version of Linux that does not support Pluggable Time Source Infrastructure. Several distros support it, but commonly only in their 64-bit OSes, and not in their 32-bit.
As others have mentioned, Integration Services allows for clock synchronization, but only if PTSI is supported. Most distros that support PTSI have the HV source already. See if there is a adjtimex port/package available for your distro.
Using NTP is a valid alternative, if you can't get PTSI working correctly. There are also some hacks including the tickadj command, and changing kernel boot variables - these should be avoided.