☰

질문에 답하다

tag-icon • tag-icon linux ntp clock ntpd systemd-timesyncd
질문에 답하다

나는 어떤 사람들에게 아주 이상한 영향을 미치는 것을 조사하고 있습니다비글 본 블랙(BBB)마더보드. 때때로 시스템 시계가 몇 달씩 점프하는 것을 볼 수 있는데, 이는 항상 systemd-timesyncd시스템 시계 업데이트와 관련이 있습니다. 우리는 다양한 위치에 있는 2,000개의 장치에서 일주일에 2~3회 이러한 현상을 확인합니다.

SNTP를 확인하는 데 많은 시간을 소비했지만 정상적으로 작동하는 것 같습니다.

우리는 결국 전자 소음으로 인해 무작위로 131072초(36시간)씩 점프할 수 있는 온보드 실시간 시계의 하드웨어 문제를 발견했습니다. 이는 즉각적으로 정확하지는 않습니다. 보고된 시간 점프는 매우 구체적이고 우리가 관찰한 것보다 훨씬 드물지만질문을 더 깊이 읽으면 점프가 더 무작위일 수 있음을 알 수 있습니다.어쩌면 거꾸로도 말이죠.

내 질문은...리눅스는 시스템 시계를 유지하기 위해 실시간 시계를 어떻게 사용합니까??

실시간 시계 오류는 시간 동기화 에이전트(ntpd 또는 systemd-timesyncd)가 업데이트될 때 시스템 시계에만 나타나는지 궁금합니다. 시스템 시계와 RTC 사이에 직접 링크가 있습니까, 아니면 에이전트에서만 사용됩니까?

노트:첫 번째 단락에서 저는 시스템 시계가 몇 달씩 점프하는 것을 볼 수 있다고 언급했는데, 이는 항상 systemd-timesyncd시스템 시계 업데이트와 관련이 있습니다. 즉, 시간 점프 후 첫 번째 syslog 메시지는 Time has been changedsyslog 메시지입니다.

grep 'Time has been changed' /var/log/syslog
Oct  2 23:53:33 hostname systemd[1]: Time has been changed
Nov 21 00:07:05 hostname systemd[1]: Time has been changed
Nov 21 00:05:17 hostname systemd[1]: Time has been changed
Nov 21 00:03:29 hostname systemd[1]: Time has been changed
Nov 21 00:01:43 hostname systemd[1]: Time has been changed
Oct  3 02:07:20 hostname systemd[1]: Time has been changed
Oct  3 06:37:04 hostname systemd[1]: Time has been changed

내가 아는 한, 이러한 메시지를 내보내는 유일한 것은 systemd-timesycnd(소스 코드 보기). 분명히 다른 사람이 systemd이와 일치하는 다른 일반 syslog 메시지를 알고 있다면 제안에 열려 있습니다.

답변1

제목을 포함하여 이러한 요점 중 일부를 반영할 수 있습니다.

[...] 이는 항상 systemd-timesyncd시스템 시계 업데이트와 관련이 있습니다. 즉, 시간 점프 후 첫 번째 syslog 메시지는 Time has been changedsyslog 메시지입니다.

grep 'Time has been changed' /var/log/syslog
Oct  2 23:53:33 hostname systemd[1]: Time has been changed

실제로 이 메시지는 어떤 프로그램이 시간 점프를 일으켰는지 알려주지 않습니다. 이것은 단지 시간 점프의 증상일 뿐입니다.

systemd이는 커널에 시계가 변경되었다는 메시지가 전달될 때 발생합니다. [*] systemd시스템 로그에 이 메시지를 기록한 다음 .timer장치를 트리거해야 하는 시기를 다시 계산하여 응답합니다.

메시지 systemd는 가 아닌 프로그램에 의해 인쇄됩니다 systemd-timesyncd.

보다 구체적으로 말하면 메시지 접두사 "systemd[1]:"은 프로세스 ID 1에서 온 것임을 나타냅니다. PID 1은 특별한 "init" 프로세스입니다. systemd 프로젝트는 systemd사용자 서비스를 관리하는 인스턴스 와 구별하기 위해 이를 "시스템 관리자"라고도 부릅니다 .

systemd시스템 부팅이 완료된 후 호출된 프로그램은 시계를 변경하지 않습니다.

연결한 현재 시스템 소스 트리에서 RTC/하드웨어 시계/hwclock을 읽는 유일한 프로그램은 이며 timedated, 로 쿼리하는 경우에만 가능합니다 timedatectl.

내가 기억하는 대로 systemd이 프로그램의 이전 버전은 다른 프로그램을 실행하기 전에 시작 시 hwclock을 한 번 읽고 이에 따라 시스템 시계를 설정했습니다. 최신 버전에서는 systemd이 작업이 수행되지 않습니다. 일부 해커만이 커널에 무엇을 알려줍니다.시간대하드웨어 클러킹에 사용됩니다. (그리고 "시간 왜곡"이라고 불리는 매우 구체적인 것을 유발하지 마십시오.)

즉, current는 systemd다른 무언가가 시스템 시계를 초기화했다고 암묵적으로 가정하는 것 같습니다. 대부분의 경우 이는 커널이 됩니다.

커널 빌드 옵션 "부팅 및 복구 시 RTC에서 시스템 시간 설정"을 찾으십시오 CONFIG_RTC_HCTOSYS.

완전한 이해를 위해 "NTP 동기화를 기반으로 RTC 시간 설정" 옵션도 있다는 점에 유의하세요 CONFIG_RTC_SYSTOHC.

[*] Linux 특정 기능을 사용하여 시스템 시계 변경을 감지합니다. 바라보다TFD_TIMER_CANCEL_ON_SET.

답변2

소스제디님 정말 감사합니다이 답변. 이것은 확실히 나를 올바른 대답으로 이끌었습니다.

질문에 답하다

Linux는 시스템 시계를 유지하기 위해 실시간 시계를 어떻게 사용합니까?

시작하는 동안 한 번만 실행됩니다. 다음에 재부팅할 때까지 RTC를 다시 쿼리하지 않습니다. 이는 구성 가능하지만 대부분의 커널 버전에서는 기본적으로 수행됩니다.

실시간 시계 오류는 시간 동기화 에이전트(ntpd 또는 systemd-timesyncd)가 업데이트될 때 시스템 시계에만 나타나는지 궁금합니다.

시스템이 재부팅되지 않는 한 RTC의 시간이 시스템 시계에 들어갈 방법은 없습니다. 일부 상담원은 다음을 좋아합니다 ntpd.RTC를 시간 소스로 사용하도록 구성그러나 이는 일반적으로 기본적으로 활성화되어 있지 않습니다. RTC가 매우 좋은 시간 소스라는 것을 알지 않는 한 RTC를 활성화하지 않는 것이 좋습니다.

시스템 클럭 사이에 직접 연결이 있습니까?

시간이 다른 방식으로 복제되는 것 같습니다. RTC는 시스템 시간을 주기적으로 업데이트합니다. sourcejedi의 답변에 따르면 이는 커널에 의해 수행됩니다.CONFIG_RTC_HCTOSYS설정되었습니다.

다음과 같이 테스트할 수 있습니다.

  • 실시간 시계 설정

    # hwclock --set --date='18:28'

  • 그런 다음 몇 분마다 RTC 시간을 확인하십시오.

    # hwclock

그 결과 시스템 시간은 전혀 변경되지 않고 RTC는 결국 시스템 시간으로 되돌아갑니다.

BBB 시간 점프의 이유

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은 기본 게이트웨이를 난잡하게 폴링하도록 하드코딩되어 있습니다. connman의 NTP 클라이언트가 활성화된 경우 DHCP를 구성하지 않고도 이 작업을 수행할 수 있습니다.(기본)그러면 다른 구성에 관계없이 이 작업을 수행합니다.

우리의 경우 일부 홈 라우터는 실제로 이러한 NTP 요청에 응답했지만 결과는 매우 신뢰할 수 없었습니다. 특히 라우터가 재부팅되는 경우정확한 시간을 알지 못한 채 계속해서 시간을 나눠준다.

예를 들어, 우리는 적어도 하나의 버전이 있다는 것을 알고 있습니다.BT 홈 센터 5재부팅 후에는 기본적으로 2018년 11월 21일로 설정되며 해당 날짜는 NTP를 통해 제공됩니다. 그러면 자체 NTP 클라이언트가 문제를 해결하지만 2018년 11월 21일을 표시하는 창이 표시됩니다.

즉, 고객이 라우터를 재부팅하고 connman이 이번에 이를 수락했기 때문에 문제가 발생했습니다.

여기서는 일부 사람들의 호전성으로 인해 connman에 이 "기능"이 너무 오랫동안 방치된 것 같다는 사실에 대한 불만을 표현하겠습니다. 2015년 초부터 문제로 보고됨. 이것은 잘 숨겨진 "기능"입니다. 구성된 시간 서버도 없고 connman이 수행하는 작업을 설명하는 로그 메시지도 없으며 이유에 대한 문서도 없습니다. 테스트 장치의 기본 게이트웨이에 NTP 서버가 없으면 테스트에서 이 서버를 볼 수 없습니다.

어떻게 고치는 지

우리는 둘 다 작동하는 것으로 보이는 두 가지 옵션을 살펴보고 있습니다.

  1. connman을 완전히 제거하십시오. 네트워크가 없어도 잘 작동하는 것 같습니다. 아직 네트워크가 존재하는 이유를 찾지 못했습니다.

    apt-get remove connman

  2. /var/lib/connman다음을 포함하도록 편집하여 connman에서 NTP를 비활성화합니다.

    [global]
TimeUpdates=manual

관련 정보