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 часов (время отчетности вчера ~ 7 вечера, когда на самом деле ~ 11 утра следующего дня). Часовой пояс правильный.

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

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

Спасибо!!

Обновить:

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

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

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

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

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

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

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

:~$ 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

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