ntpd는 timesyncd와 마찬가지로 동적 네트워크 구성을 잘 처리합니다.안 돼요동적 네트워크 구성을 다룰 때 실제 NTP 데몬이 자동으로 올바른 작업을 수행할 때 이 문제를 해결하기 위해 스크립트를 사용하는 것은 의미가 없다고 생각합니다. ntpdate(및 tlsdate와 같은 다른 소프트웨어)는 독립형 도구로는 적합하지만 자동으로 호출하는 것은 현명하지 않은 것 같습니다. (또한 시작이나 네트워크 변경 시에만 업데이트하는 것보다 시간을 지속적으로 최신 상태로 유지하는 것이 더 합리적입니다.)
나는 논쟁의 적어도 일부를 이해합니다. 최신 PC에서는 경량 데몬을 실행하여 시계를 정확하게 유지하는 것이 합리적입니다.
네트워크 구성은 동적이며 NTP 데몬은 특정 네트워크 구성 시스템과 통합되지 않는다고 가정합니다. 일반적인 인터페이스(일부 Linux 커널 인터페이스 포함)만 사용합니다. 이 작업을 수행하려면 무엇이 필요합니까?
역사적으로 네트워크 시스템이 스크립트를 실행하도록 하여 구체적으로 통합하는 것이 일반적이었습니다. 그런데 검색해보니 systemd-networkd스크립트 후크가 구현되어 있지 않은 것 같습니다. 위의 링크를 보면 적어도 개발자가 스크립트 후크를 그다지 좋아하지 않는다는 것을 알 수 있습니다.
이 질문은 약간 가정적입니다. 비슷한 문제를 염두에 두고 있으므로 NTP가 이 문제를 어떻게 처리하는지 알고 싶습니다.
NTP를 동기화하려는 초기 시도가 실패한 것으로 판단되면 한 시간 후에 다시 시도하는 등의 간단한 접근 방식으로 충분할 것이라고 가정합니다. [*]
a) 내 질문은 시작을 시도해야 할 때를 어떻게 감지하는가입니다. 이는 NTP 클라이언트를 사용하도록 구성한 서버에 따라 다를 수 있다고 생각합니다. 예를 들어
- DNS 서버가 구성되었습니까?
- DNS 서버로의 라우팅을 구성했습니까? (기본 라우팅은 괜찮지만 모든 상황에서 작동하지 않을 수 있습니다.)
- DNS 서버인가요?이 인터페이스의 경우구성되었으며 액세스 가능합니까? (예를 들어 여러 인터페이스에서 비전역 DNS 이름에 대한 systemd-networkd 지원을 사용하는 경우)
- /etc/hosts 또는 MDNS를 사용하는 등 DNS 서버를 사용하지 않고 NTP 서버 호스트 이름이 확인됩니까?
- NTP 서버로의 라우팅을 구성했습니까?
b) pool.ntp.org 서버에 대해 예의를 갖춰야 합니다. 그렇다면 가능한 모든 네트워크 구성 이벤트가 발생한 후 즉시 재시도하고 싶지는 않은 것 같습니다.
systemd-resolvedc) DNS 서버가 구성될 때 이를 감지(또는 NetworkManager+dnsmasq 또는...)하려면 해당 네트워크 구성 시스템과의 특정 통합이 필요합니다. 그렇죠? systemd-networkd의 경우 DBus 인터페이스를 사용하여 ntp 클라이언트를 통합해야 합니다. 그렇죠?
[*] 일반적으로 네트워크 연결이 더 간단하기 때문입니다. 일반적으로 글로벌 인터넷 및 DNS에 대한 활성 연결이 있는 단일 라우터에 직접 연결할 수 있습니다. 또는 네트워크가 내부적으로 더 복잡하지만 개별 구성 요소의 실패/복구 빈도가 더 낮습니다. 예를 들어 일반적으로 우리는 인터넷 연결 시간이 50%인 메시 네트워크를 사용하려고 시도하지 않습니다.
답변1
비확산
ntpdNTP 데몬을 참조합니다 . 전체 메시지 if-up.d에는 Debian의 스크립트 후크 목록이 포함되어 있습니다. ntpd(또는) 후크 스크립트가 없습니다 chrony. NTP 관련 스크립트는 ntpdate및 뿐입니다 openntpd.
ntpd서버로부터 응답이 수신되지 않으면 64초 후에 패킷을 다시 보내는 것으로 생각됩니다 .
응답하지 않는 NTP 서버에 대한 재시도 간의 최소 간격은 얼마입니까?
편집: 그러나 재시도가 여러 번 실패하면 재시도 간격이 늘어나 결국 1024초에 도달합니다. (두 값 모두 구성 가능하지만 기본값입니다.)
문서 ntpd는 또한 "모뎀 호출이 완료될 수 있도록" 어느 정도 시간이 선택되었다고 주장합니다. 이는 ntpd명시적인 알림 없이 동적으로 설정된 네트워크 연결과 끊어진 네트워크 연결을 지원할 수 있도록 설계된 것처럼 들립니다. 그러나 해당 부분은 오해의 소지가 있는 것 같습니다. 위의 최대 재시도 간격을 고려하면 기본 설정이 모든 경우에 적합하지는 않다고 생각합니다.
만성병 환자
대조적으로,기타 참고자료ntp부분적으로 DNS 문제로 인해 전화 접속 사용에는 적합하지 않습니다 . 이는 chrony더 잘 작동하지만 스크립트 후크를 사용하도록 설계되었습니다. Fedora Linux 29의 chrony-3.4 패키지에는 후크 스크립트가 포함되어 있습니다 /etc/NetworkManager/dispatcher.d/20-chrony.
시스템 시간 동기화
systemd-timesyncdsystemd-networkd다른 것과 통합하지 마십시오. 현재는 문서화되지 않은 인터페이스를 사용하는 것으로 보입니다.
systemd-timesyncd가 온라인이라고 생각하고 "연결"할 수 없는 것 같습니다.30초마다 다시 시도.
systemd-networkd처음에는 DBus 인터페이스가 없었습니다.. 아니면 오히려 그것이 가지고 있는 것은 고려되지 않는다.준비해하지만.
의미론을 사용하여 후크 스크립트를 실행하는 것이 가능한 것 같습니다 systemd-networkd. 사용 가능한 의미 체계의 일부 차이로 인해 if-up.d모든 후크 스크립트를 자동으로 실행하는 것은 좋은 생각이 아닙니다. (질문에 링크된 데비안 버그 스레드에 명시된 바와 같이). 바라보다:
systemd-networkd를 사용하여 네트워크 구성 변경 시 작업 수행
[*] 이것은 또한 디자인이 ntpd고대로 들리게 하기 때문에가능한현대적인 고려 사항과 완전히 일치하지 않습니다. 예를 들어, 배터리로 작동되는 소형 태블릿 장치의 경우입니다. [**] 서버가 응답하지 않으면 64초마다 다시 시도하시겠습니까? 편집: 시스템은 64초마다 무기한 재시도하지 않습니다. 연결할 수 없는 기간이 지나면 폴링 간격이 늘어납니다. ("poll() 루틴에는 서버에 연결할 수 없는 경우 폴링 간격을 줄이는 기능이 포함되어 있습니다...")
[**] 내가 이해한 바에 따르면 "모바일" 등급 장치는 네트워크 하드웨어(CPU를 깨우지 않고 ARP에 응답할 수 있는 경우)를 제외하고 밤새 머물면서 대부분의 시스템을 일시 중지할 수 있도록 설계되었습니다. 암호화 키(예: WPA)를 순환할 수 있습니다.