Я запускаю ntpd на своем компьютере, но не уверен, что он работает правильно. Как я могу запросить ntpd, чтобы определить, успешно ли он подключился к серверам времени и синхронизировано ли время моего ядра?

3
Martin von Wittich 22 Апр 2021 в 15:10

1 ответ

Есть несколько способов определить, работает ли ntpd:

  1. Используйте ntpq -p (или ntpq -pn, чтобы сэкономить время, пропустив поиск DNS).

    Вот как это выглядит, когда NTP работает:

    host-a ~ # ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
     1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
     2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
     3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
    +mail.masters-of 144.76.76.107    3 u  975 1024  377   13.731   -0.737   2.552
    +ntp2.hetzner.de 124.216.164.14   2 u  232 1024  377   15.914   -0.650   0.854
    +rondra.lf-net.o 237.17.204.95    2 u 1020 1024  377   13.751   -0.557   4.292
    -funky.f5s.de    131.188.3.222    2 u  480 1024  377   15.730    2.082   4.377
    +stratum2-3.NTP. 129.70.137.82    2 u  742 1024  377   19.785   -0.366   7.498
    *mail.klausen.dk 193.79.237.14    2 u  173 1024  377   14.383   -0.513   2.066
    

    Он перечислит фактические пиры, к которым он подключен; * указывает источник, с которым выполняется синхронизация. Более подробная информация о выводе доступна в документы NTP.

    Вот как это выглядит, когда это не так:

    host-b ~ # ntpq -p
         remote           refid      st t when poll reach   delay   offset  jitter
    ==============================================================================
     0.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
     1.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
     2.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
     3.debian.pool.n .POOL.          16 p    -   64    0    0.000    0.000   0.000
    

    Обратите внимание, что в списке нет реальных пиров, что обычно указывает на то, что ntpd не смог подключиться ни к одному из них, вероятно, из-за того, что брандмауэр предотвратил подключения.

    ntpq -p не подходит для проверки по сценарию, потому что вывод должен быть проанализирован, и хотя его скорость (30 мс для одного вызова) неплохая, есть более быстрые способы, которые я собираюсь обсудить позже. на.

  2. Если вы используете systemd, вы можете использовать timedatectl status.

    Вот как это выглядит, когда работает NTP (обратите внимание на System clock synchronized: yes):

    host-a ~ # timedatectl status 
                   Local time: Do 2021-04-22 13:29:20 CEST
               Universal time: Do 2021-04-22 11:29:20 UTC
                     RTC time: Do 2021-04-22 11:29:21
                    Time zone: Europe/Berlin (CEST, +0200)
    System clock synchronized: yes
                  NTP service: inactive
              RTC in local TZ: no
    

    Вот как это выглядит, когда это не так (обратите внимание на System clock synchronized: no):

    host-b ~ # timedatectl status
                   Local time: Do 2021-04-22 13:29:53 CEST
               Universal time: Do 2021-04-22 11:29:53 UTC
                     RTC time: Do 2021-04-22 11:29:42
                    Time zone: Europe/Berlin (CEST, +0200)
    System clock synchronized: no
                  NTP service: inactive
              RTC in local TZ: no
    
    

    (NTP service относится к systemd-timesyncd, собственному NTP-клиенту systemd. Он не должен работать, пока ntpd установлен, поэтому no должен быть Ожидается здесь.)

    timedatectl status запросы systemd-timedated, которые запускаются только по запросу, что приводит к небольшому снижению производительности ~100 мс при первом вызове; дальнейшие вызовы занимают около ~ 12 мс.

    systemd-timedated, в свою очередь, использует системный вызов adjtimex(2) для запроса ядра; если adjtimex(2) возвращает статус с установленным битом STA_UNSYNC, часы не синхронизированы. Это означает, что timedatectl на самом деле не взаимодействует с ntpd, а вместо этого запрашивает бит, хранящийся в ядре, который службы NTP, такие как ntpd, будут обновлять при каждом изменении состояния синхронизации.

    timedatectl status хорошо подходит для сценариев, поскольку вы можете напрямую запрашивать соответствующее свойство:

    host-a ~ # timedatectl show -p NTPSynchronized --value                          
    yes
    host-b ~ # timedatectl show -p NTPSynchronized --value
    no
    
  3. Используйте adjtimex(2) напрямую:

    Это наименее удобный подход, но самый быстрый для сценариев. busybox, предоставленный Debian buster, имеет апплет adjtimex, который служит простой оболочкой для системного вызова adjtimex(2).

    Вот как это выглядит, когда NTP работает:

    host-a ~ # busybox adjtimex
        mode:         0
    -o  offset:       -570098 us
    -f  freq.adjust:  857283 (65536 = 1ppm)
        maxerror:     478704
        esterror:     302
        status:       8193 (PLL)
    -p  timeconstant: 10
        precision:    1 us
        tolerance:    32768000
    -t  tick:         10000 us
        time.tv_sec:  1619092119
        time.tv_usec: 60467600
        return value: 0 (clock synchronized)
    

    Вот как это выглядит, когда это не так (обратите внимание на UNSYNC в строке status и на ):

    host-b ~ # busybox adjtimex
        mode:         0
    -o  offset:       0 us
    -f  freq.adjust:  2126708 (65536 = 1ppm)
        maxerror:     16000000
        esterror:     16000000
        status:       16449 (PLL | UNSYNC)
    -p  timeconstant: 7
        precision:    1 us
        tolerance:    32768000
    -t  tick:         10000 us
        time.tv_sec:  1619091984
        time.tv_usec: 307119
        return value: 5 (clock not synchronized)
    

    К сожалению, busybox adjtimex, по-видимому, не дает возможности печатать только определенное поле, а возвращаемое значение только печатается, а не возвращается. Это означает, что для сценариев вам придется анализировать вывод (например, busybox adjtimex | grep -q UNSYNC). С другой стороны, это компенсируется чрезвычайной скоростью — всего 0,5 мс!

6
Martin von Wittich 22 Апр 2021 в 15:10
2
Обратите внимание, что вы можете указать, какая служба timedatectl будет отображаться как «служба NTP:», установив переменную среды SYSTEMD_TIMEDATED_NTP_SERVICES для systemd-timedated.service. Например, если вы установите переменную как SYSTEMD_TIMEDATED_NTP_SERVICES=chronyd.service:ntpd.service, то timedated (а также timedatectl) будет искать chronyd.service, а затем ntpd.service. Старые версии systemd могут не включать эту функцию.
 – 
telcoM
22 Апр 2021 в 15:26