Время Ubuntu 16.04 прекращает синхронизировать сбои timedatectl для запросов сервера, но timesyncd активен

Исходный вопрос:

Посмотрите обновления ниже.

Я надеюсь, что могу получить некоторую помощь, работающую через проблему, которую я имел на своем сервере Ubuntu. Я выполняю настольную версию 16,04 как сервер, и иногда я замечал, что системное время выходит из обновления синхронизации/остановок. Обычно это предшествует общей сумме убытков удаленного доступа и требует, чтобы перезапуск зафиксировал. Вот вывод systemctl состояния systemd-timesyncd.service:

    systemd-timesyncd.service - Network Time Synchronization
    Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; 
    vendor preset: enabled
    Drop-In: /lib/systemd/system/systemd-timesyncd.service.d
       └─disable-with-time-daemon.conf
    Active: active (running) since Fri 2018-10-19 00:17:02 PDT; 2 days ago
    Docs: man:systemd-timesyncd.service(8)
    Main PID: 642 (systemd-timesyn)
    Status: "Synchronized to time server 91.189.91.157:123 
    (ntp.ubuntu.com)."
    CGroup: /system.slice/systemd-timesyncd.service
       └─642 /lib/systemd/systemd-timesyncd
    Oct 19 00:17:02 eric-SFF systemd[1]: Starting Network Time 
    Synchronization...
    Oct 19 00:17:02 eric-SFF systemd[1]: Started Network Time 
    Synchronization.
    Oct 19 00:37:24 eric-SFF systemd-timesyncd[642]: Synchronized to time 
    server 91.189.94.4:123 (ntp
    Oct 19 10:19:00 eric-SFF systemd-timesyncd[642]: Timed out waiting for 
    reply from 91.189.94.4:123
    Oct 19 10:19:00 eric-SFF systemd-timesyncd[642]: Synchronized to time 
    server 91.189.91.157:123 (n

И вот вывод timedatectl:

~$ timedatectl
Failed to query server: Connection timed out

Системное время в этой точке было выключено приблизительно на 12 часов (сообщающий о времени вчера ~ 19:00, когда это - на самом деле ~ 11:00 на следующий день). Часовой пояс корректен.

Я также заметил, что мои задания крона прекращают работать, когда это происходит, поскольку у меня есть задание крона, которое проверяет интернет-соединение на равных интервалах и сообщает о его выводе файлу журнала. Это, которое файл журнала прекращает обновлять в то же время, когда время выходит из синхронизации. У меня также есть задание крона, которое создает резервную копию определенных каталогов, и эти резервные копии не актуальны.

Сообщите мне, была ли дополнительная информация полезна. Я - все еще относительный новичок к Ubuntu.

Спасибо!!

Обновление:

@Damocles спасибо за Ваше предложение. Да, компьютер имеет рабочее сетевое соединение. У меня не было набора правил брандмауэра для разрешения NTP (порт 123) через UFW или мой брандмауэр на моем маршрутизаторе Ubiquiti. Однако это все еще работало бы некоторое время (иногда недели за один раз) прежде, чем прослушивать. Это могло все еще быть проблемой брандмауэра?

Я шел вперед и добавил правило ufw и добавил исключение брандмауэра и трансляцию NAT в моем маршрутизаторе и перезагрузил сервер. Это синхронизирует на данный момент, но мой брандмауэр, казалось, не был в пути, потому что транспортный счет для того правила не увеличился.

Есть ли что-либо еще, что могло блокировать это соединение? Возможно, что-то, что позволило бы этому работать сначала, но вызывать, отбрасывало/блокировало доступ NTP по линии?

Я также нашел, что эта команда проверила состояние синхронизации времени, но это возвращается и неизвестная операционная ошибка:

:~$ timedatectl timesync-status
Unknown operation timesync-status

Новое обновление 01.11.18

Я установил chrony, как предложено, но все еще получение той же проблемы, в течение 24 часов. Что-то определенно неправильно. И спустя ~16 часов после новой начальной загрузки и установленного chrony, вот вывод некоторых команд chrony:

:~$ chronyc sources
210 Number of sources = 11
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===========================================================================
^? up2.com                       0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? 216-228-47-167.midrivers.     0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? blue.1e400.net                0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? 12.167.151.1                  0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? lithium.constant.com          0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? clock.xmission.com            0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? ha81.smatwebdesign.com        0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? srcf-ntp.stanford.edu         0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? time1.plumdev.net             0   6   377   10y     +0ns[   +0ns] +/-            
0ns
^? SunSITE.icm.edu.pl            0   6   377   10y     +0ns[   +0ns] +/-    
0ns
^? time.no-such-agency.net       0   6   377   10y     +0ns[   +0ns] +/-    
0ns
:~$ chronyc sourcestats
210 Number of sources = 11
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset  Std 
Dev
============================================================================
up2.com                     0   0     0     +0.000   2000.000     +0ns  
4000ms
216-228-47-167.midrivers.   0   0     0     +0.000   2000.000     +0ns  
4000ms
blue.1e400.net              0   0     0     +0.000   2000.000     +0ns  
4000ms
12.167.151.1                0   0     0     +0.000   2000.000     +0ns  
4000ms
lithium.constant.com        0   0     0     +0.000   2000.000     +0ns  
4000ms
clock.xmission.com          0   0     0     +0.000   2000.000     +0ns  
4000ms
ha81.smatwebdesign.com      0   0     0     +0.000   2000.000     +0ns  
4000ms
srcf-ntp.stanford.edu       0   0     0     +0.000   2000.000     +0ns  
4000ms
time1.plumdev.net           0   0     0     +0.000   2000.000     +0ns  
4000ms
SunSITE.icm.edu.pl          0   0     0     +0.000   2000.000     +0ns  
4000ms
time.no-such-agency.net     0   0     0     +0.000   2000.000     +0ns  
4000ms

Я верю "Досягаемости", являющейся ненулевыми средствами, это заканчивает брандмауэр, таким образом, я не думаю, что это - проблема. Кроме того, эти команды возвратили нормальный вывод сначала.