Работает ли ntpd?

Существует несколько способов определить, работает ли 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относится к собственному NTP-клиенту systemd-timesyncd, 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 мс!