일부 (하드웨어) 서버에서 이상한 시스템 시간 변경 동작이 나타납니다. 에서 /var/logs/syslog
각 로그 메시지 전의 날짜/시간은 때때로 다음과 같이 임의의 날짜로 변경되고 다음 메시지에서는 정상으로 돌아갑니다.
Feb 22 2018 09:09:30 ...
Feb 22 2018 09:09:32 ...
Jan 13 2610 15:37:42 ...
Feb 22 2018 09:09:33 ...
Feb 22 2018 09:09:34 ...
예제에 표시된 것처럼 날짜/시간의 급격한 변경은 수백 년에 걸쳐 발생할 수 있습니다.
이상한 타임스탬프가 있는 로그 메시지가 특정 프로세스에서 나오는 것이 아니라는 것을 확인할 수 있습니다. 모든 프로세스에서 무작위로 발생할 수 있습니다.
두 번의 비정상적인 시간 변경 사이의 지속 시간은 몇 분에서 몇 시간까지 다양할 수 있습니다(단, 비정상적인 시간 변경이 더 자주 발생할 수도 있다고 생각하지만, 1초마다 기록되지 않기 때문에 시스템 로그에 표시되지 않는 경우도 많습니다) 로그에).
그리고 여러 대의 서버에서 발생하기 때문에 하드웨어 문제는 아닌 것 같습니다.
서버에 대한 추가 정보: 컨트롤러와 일부 컴퓨팅 노드가 포함된 OpenStack 설치입니다. 각 서버는 ntp 서비스를 실행합니다. 컨트롤러는 자체 하드웨어 시계에서 시간을 얻도록 구성되고 컴퓨팅 노드 서버는 컨트롤러의 시간을 동기화합니다. 각 서버에는 고유한 시간 변화가 있습니다. "잘못된 시간"이 컨트롤러에서 ntp를 통해 동기화되지 않은 것처럼 보입니다.
컴퓨팅 노드의 게스트 시스템(가상 머신)이 호스트 시스템 시간에 영향을 미치는 것으로 의심됩니다. 그러나 가상 머신을 실행하지 않고도 컨트롤러에 동일한 문제가 발생하는 이유는 설명되지 않습니다.
감지할 방법이 필요합니다. 누가 시스템 시간을 변경했으며 어떻게 변경되었나요?
답변1
관련 측면은 커널 버전과 부팅 프로세스 초기의 다음 줄입니다.
kernel: Fast TSC calibration using PIT
...
kernel: Calibrating delay loop (skipped), value calculated using timer frequency..
...
kernel: Switching to clocksource tsc
YMMV 및 TSC 또는 PIT를 사용하지 않을 수 있습니다.
AFAIK 이것은 적어도 하나의 CPU 시계가 동기화되지 않아 발생하는 버그로, 귀하의 경우 너무 빠르게 실행될 수 있습니다.
다음 명령을 실행하면 쉽게 확인할 수 있습니다.
for cpu in {0..8} ; do taskset -c $cpu date ; done
이는 date
각 CPU에 대해 실행됩니다(최대 8개의 코어/스레드가 있다고 가정). 내 추측이 맞다면 CPU 중 하나는 항상 잘못된 시간을 갖게 됩니다.
이 경우 먼저 커널 업그레이드를 시도해야 하며, 그래도 작동하지 않으면 Clocksource 시작 매개변수를 수정하십시오(라고 가정 x86-64
).
clocksource= Override the default clocksource
Format: <string>
Override the default clocksource and use the clocksource
with the name specified.
Some clocksource names to choose from, depending on
the platform:
[all] jiffies (this is the base, fallback clocksource)
[ACPI] acpi_pm
...
[X86-64] hpet,tsc
다음 출력도 참조하세요.
cat /sys/devices/system/clocksource/clocksource*/available_clocksource
답변2
복사한 곳:CRON 메시지가 시스템 로그에서 임의로 오랜 시간 동안 지연됩니다.:
간단히 말해서, 내가 사용하고 있는 rsyslog 버전에는 임의의 시간 동안 들어오는 syslog 메시지를 지연시키는 버그가 있습니다.여기에 버그 보고서가 있습니다. rsyslog를 업그레이드하면 문제가 해결되었습니다. 이는 CRON의 잘못이 아닙니다.
답변3
컨트롤러 서버의 하드웨어 시계는 시간에 대한 안정적인 정보 소스가 아닌 것 같습니다. 해당 유형을 보다 안정적인 원자 시계와 동기화하도록 컨트롤러를 구성해야 합니다.
하드웨어 시계를 업데이트하는 데 사용할 수 있는 명령은 다음과 같습니다.
hwclock -s
또한보십시오:
-s, --hctosys
Set the System Time from the Hardware Clock.
Also set the kernel's timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them. The obsolete tz_dsttime field of the kernel's time‐
zone value is set to DST_NONE. (For details on what this field used to mean, see settimeofday(2).)
This is a good option to use in one of the system startup scripts.
-w, --systohc
Set the Hardware Clock to the current System Time.
답변4
이러한 이상 현상을 방지하려면 Tier 1 또는 Tier 2 소스와 동기화되는 외부 NTP 서버를 사용해야 합니다. 하드웨어 시계가 신뢰할 수 없습니다.