Eu tenho uma configuração bastante simples, onde tenho dois computadores:
O computador A. tem uma configuração NTP normal e usa as fontes padrão da Internet (conforme o Ubuntu) para determinar o tempo. Também permite a consulta no IP 10.0.2.0/24:
restrict 10.0.2.0 mask 255.255.255.0 nomodify notrap
O computador B. tem uma configuração NTP normal, exceto que todas as fontes são alteradas para uso 10.0.2.1(que é o computador A).
De vez em quando, o Computador A recebe um sinal de Beijo da Morte de uma de suas fontes. Como resultado, ele mata totalmente o NTP do Computador B (ou seja, parece que o KoD é transmitido diretamente).
Existe uma maneira de saber o estado de um servidor NTP em termos de se ele enviará apenas uma mensagem KoD ou não? (além disso, como saio dessa situação? Quando olhei para ele, todos os endereços IP mostrados no log não foram usados pelo servidor?! então não entendo porque insiste em enviar KoD para seu cliente) .
Encontrei duas coisas até agora:
ntpqEu posso rodar
ntpqassim:ntpq -pnQuando o servidor NTP funciona, posso ver um asterisco na frente do endereço IP com o qual o computador está satisfeito. No meu caso, todos os sinalizadores de status (primeira coluna
+,-,*,#etc.) desaparecem. Até onde eu sei, isso significa que o serviço NTP não está satisfeito e nenhuma sincronização está sendo executada.Aqui está um exemplo quando ainda funciona (ou seja, há sinalizadores na primeira coluna):
remote refid st t when poll reach delay offset jitter ============================================================================== 10.0.2.255 .BCST. 16 B - 64 0 0.000 0.000 0.000 #51.77.203.211 134.59.1.5 3 u 4 64 1 171.248 -743.64 691.917 +72.5.72.15 216.218.254.202 2 u 2 64 1 19.223 -778.34 686.200 +159.69.25.180 192.53.103.103 2 u 3 64 1 237.733 -775.41 701.376 +173.0.48.220 43.77.130.254 2 u 2 64 1 35.489 -778.85 669.187 38.229.56.9 172.16.21.35 2 u 31 64 1 153.976 -268.90 122.557 +137.190.2.4 .PPS. 1 u 31 64 1 93.797 -253.69 116.289 +150.136.0.232 185.125.206.71 3 u 35 64 1 95.667 -178.19 114.912 94.154.96.7 194.29.130.252 2 u 31 64 1 237.560 -231.88 107.230 +162.159.200.123 10.4.1.175 3 u 34 64 1 16.246 -199.68 115.561 *216.218.254.202 .CDMA. 1 u 35 64 1 52.906 -193.84 131.148 91.189.91.157 132.163.96.1 2 u 45 64 1 87.772 -5.716 0.000 +204.2.134.163 44.24.199.34 3 u 34 64 1 16.711 -199.12 116.777 +74.6.168.73 208.71.46.33 2 u 35 64 1 69.772 -189.21 128.119 91.189.89.199 17.253.34.123 2 u 45 64 1 165.471 -3.708 0.000 +216.229.0.49 216.218.192.202 2 u 35 64 1 71.437 -178.94 97.505 91.189.89.198 17.253.34.123 2 u 44 64 1 172.852 -17.899 0.000ntpdate -q <ip>O
ntpdatecomando realmente me dirá se o NTP está aceitando pacotes. Isso ocorre porque dá uma mensagem de erro se não:$ sudo ntpdate -q 10.0.2.1 server 10.0.2.1, stratum 4, offset 5.194725, delay 0.02652 21 Jul 15:22:48 ntpdate[13086]: no server suitable for synchronization foundIsso acontece depois de um tempo quando meu servidor principal perde o
*status no servidor com o qual ele estava feliz em sincronizar ...
Agora... ainda preciso entender o que tenho que fazer para corrigir esse problema...
Isso pode ser útil, aqui estão os logs sobre uma reinicialização de uma reinicialização completa:
Jul 21 18:29:13 vm-ve-ctl kernel: [ 434.275481] audit: type=1400 audit(1626917353.636:43): apparmor="DENIED" operation="open" profile="/usr/sbin/ntp
d" name="/snap/bin/" pid=3896 comm="ntpd" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
Jul 21 18:29:13 vm-ve-ctl ntpd[3896]: ntpd [email protected] (1): Starting
Jul 21 18:29:13 vm-ve-ctl ntpd[3896]: Command line: /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 126:129
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: proto: precision = 0.190 usec (-22)
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Cannot open logfile /var/log/ntp.log: Permission denied
Jul 21 18:29:13 vm-ve-ctl kernel: [ 434.291490] audit: type=1400 audit(1626917353.652:44): apparmor="DENIED" operation="capable" profile="/usr/sbin/
ntpd" pid=3901 comm="ntpd" capability=1 capname="dac_override"
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): good hash signature
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: leapsecond file ('/usr/share/zoneinfo/leap-seconds.list'): loaded, expire=2021-12-28T00:00:00Z last=2017-01-01T
00:00:00Z ofs=37
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen and drop on 0 v6wildcard [::]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen and drop on 1 v4wildcard 0.0.0.0:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 2 lo 127.0.0.1:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 3 enp0s3 192.168.2.120:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 4 enp0s8 10.0.2.1:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 5 lo [::1]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 6 enp0s3 [fe80::a00:27ff:fe25:38ff%2]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listen normally on 7 enp0s8 [fe80::a00:27ff:fe35:c30b%3]:123
Jul 21 18:29:13 vm-ve-ctl ntpd[3901]: Listening on routing socket on fd #24 for interface updates
Jul 21 18:29:14 vm-ve-ctl ntpd[3901]: Soliciting pool server 51.77.203.211
Jul 21 18:29:15 vm-ve-ctl ntpd[3901]: Soliciting pool server 159.69.25.180
Jul 21 18:29:15 vm-ve-ctl ntpd[3901]: Soliciting pool server 72.5.72.15
Jul 21 18:29:16 vm-ve-ctl ntpd[3901]: Soliciting pool server 198.251.86.68
Jul 21 18:29:16 vm-ve-ctl ntpd[3901]: Soliciting pool server 173.0.48.220
Jul 21 18:29:16 vm-ve-ctl ntpd[3901]: Soliciting pool server 38.229.56.9
Jul 21 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 150.136.0.232
Jul 21 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 94.154.96.7
Jul 21 18:29:17 vm-ve-ctl ntpd[3901]: Soliciting pool server 137.190.2.4
Jul 21 18:29:18 vm-ve-ctl ntpd[3901]: Soliciting pool server 162.159.200.123
Jul 21 18:29:18 vm-ve-ctl ntpd[3901]: Soliciting pool server 216.218.254.202
Jul 21 18:29:18 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.91.157
Jul 21 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.89.199
Jul 21 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 74.6.168.73
Jul 21 18:29:19 vm-ve-ctl ntpd[3901]: Soliciting pool server 204.2.134.163
Jul 21 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 91.189.89.198
Jul 21 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 216.229.0.49
Jul 21 18:29:20 vm-ve-ctl ntpd[3901]: Soliciting pool server 2604:ed40:1000:1711:d862:f5ff:fe4e:41c4
Jul 21 18:29:21 vm-ve-ctl ntpd[3901]: receive: Unexpected origin timestamp 0xe4a34871.ac57f05d does not match aorg 0000000000.00000000 from [email protected] xmt 0xe4a34871.65648c54
Não sei exatamente quando começa a ficar ruim. Eu também vi o seguinte que eu pensei que poderia ter algo a ver com isso (ou seja, quando isso acontece, o IP correspondente é removido da lista!), mas já está ruim agora e nenhum erro ocorreu na minha última execução.
Jul 21 18:08:57 vm-ve-ctl ntpd[9764]: 92.243.6.5 local addr 192.168.2.120 -> <null>
Nota: o 192.168.2.120 é o IP do computador com falha. É um VirtualBox. Está funcionando há meses... porém, talvez algo tenha mudado, o que o torna infeliz.
Encontrei este post sobre um problema com a ... -> <null>mensagem. No entanto, acho que temos uma versão mais recente no Ubuntu 18.04:
Versão mínima recomendada do SUSE: Versão do ntp-4.2.8p7-11.1
Ubuntu 18.04:1:4.2.8p10+dfsg-5ubuntu7.3
Por precaução, tentei conectar a VM ao host e ainda recebo um enorme deslocamento e jitter. O que poderia ter mudado?!
remote refid st t when poll reach delay offset jitter
==============================================================================
10.0.2.10 .POOL. 16 p - 64 0 0.000 0.000 0.000
10.0.2.10 132.163.97.6 2 u 54 64 3 0.457 -5254.2 3917.68
Conforme solicitado por Paul Gear, aqui está a saída do ntpq com detalhes adicionais:
$ ntpq -ncrv
associd=0 status=0028 leap_none, sync_unspec, 2 events, no_sys_peer,
version="ntpd [email protected] (1)", processor="x86_64",
system="Linux/4.15.0-151-generic", leap=00, stratum=4, precision=-23,
rootdelay=17.930, rootdisp=5019.260, refid=173.255.215.209,
reftime=e4a44f7a.1c2ec778 Thu, Jul 22 2021 13:11:38.110,
clock=e4a45030.c8a4b259 Thu, Jul 22 2021 13:14:40.783, peer=0, tc=6,
mintc=3, offset=-109.527915, frequency=-1.707, sys_jitter=0.000000,
clk_jitter=38.724, clk_wander=0.000, tai=37, leapsec=201701010000,
expire=202112280000
Aqui está a lista de relógios disponíveis e o usado atualmente:
$ grep . /sys/devices/system/clocksource/clocksource*/[ac]*clocksource
/sys/devices/system/clocksource/clocksource0/available_clocksource:kvm-clock tsc acpi_pm
/sys/devices/system/clocksource/clocksource0/current_clocksource:kvm-clock
E, finalmente, a dmesgsaída sobre o processo de seleção de clocksource:
$ dmesg | grep clocksource
[ 0.000000] clocksource: kvm-clock: mask: 0xffffffffffffffff max_cycles: 0x1cd42e4dffb, max_idle_ns: 881590591483 ns
[ 0.000000] clocksource: refined-jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645519600211568 ns
[ 0.283117] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 7645041785100000 ns
[ 1.161844] clocksource: Switched to clocksource kvm-clock
[ 1.208316] clocksource: acpi_pm: mask: 0xffffff max_cycles: 0xffffff, max_idle_ns: 2085701024 ns
[ 2.329228] clocksource: tsc: mask: 0xffffffffffffffff max_cycles: 0x1db81a3240f, max_idle_ns: 440795250379 ns
Parece que encontrei uma solução. Eu não estou muito certo por que teria funcionado antes, no entanto.
Depois de muitas pesquisas, encontrei este ticket do VirtualBox:
https://www.virtualbox.org/ticket/15179
que diz que você não deve usar
ntpdporque a VM já mantém o tempo usando o Host time para ajustar o relógio virtual da VM .No entanto, mesmo sem
ntpdfuncionar, o relógio da minha VM estava desligado e saltava entre ± 30 segundos em um curto período de tempo.Lendo mais a postagem, eles se ofereceram para ajustar as configurações de paravirtualização para "Nenhuma". Isso não parecia funcionar para mim. Reiniciei a VM e ela travou. Então eu tentei com "Minimal" e agora o relógio está funcionando. A
ntpq -npsaída parece muito melhor:Como podemos ver, o Offset (máximo 4,3) e Jitter (máximo 6,7) são minúsculos comparados ao que eu estava recebendo antes. Agora meu outro computador também funciona e pode se sincronizar com este relógio. O atraso é em torno de 0,7, o que é suficiente para mim (no meu caso, o suficiente é 12,0 ou menos).
NOTA IMPORTANTE: reiniciei essa VM 2 ou 3 vezes usando Minimal , o tempo de inicialização é terrivelmente longo. Portanto, não recomendo usar esse modo, exceto como último recurso, se você realmente precisar de um relógio do sistema funcionando. Se você tiver uma solução melhor que funcione, sou todo ouvidos!
Apenas no caso, eu queria ver a diferença em relação às fontes de clock no modo Minimal . Acabamos de receber o
acpi_pmrelógio.Agora eu estou querendo saber se isso poderia ter um efeito sobre o relógio do host. Como também tenho ntp no meu host, não acho que isso seja um problema.
Ok, bastante incomum, estou adicionando uma segunda resposta porque isso 100% explica por que começou a quebrar. Dentro de alguns dias após a última reinicialização, há uma atualização do driver NVidia. Então eu iniciei minha VM (ou seja, o pedido é muito importante aqui!)
Eu não sabia que o ambiente 3D poderia estar ausente e, se não fosse acelerado, a VM se comportaria totalmente mal em termos de relógio/hora.
Observe que o fato de o ambiente 3D não estar disponível não foi visível para mim. Pode ter sido mencionado em alguns logs, mas como usuário padrão , perdi completamente essa parte.
Após uma reinicialização completa (exigida por essa atualização da NVidia), a VM funciona normalmente novamente. Não há necessidade de usar a opção Mínimo . Eu coloquei essa VM de volta ao padrão e ela funciona bem como antes.
Espero que isso poupe algumas pessoas da dor de cabeça que tive por 3 dias...
Para os interessados, mudar o relógio também pode ajudar. A Oracle tem uma boa página sobre como alterar a fonte do relógio . Do meu lado, acabei usando o
apci_pmque parece ajudar bastante na manutenção do tempo por muito tempo.Você também pode atualizar seus parâmetros de inicialização para que, cada vez que inicializar, obtenha essa fonte selecionada.
(Eu removi parâmetros irrelevantes aqui, não os exclua, apenas adicione o
clocksourceparâmetro; também pode ser que a variável esteja vazia na primeira vez que você a edita:GRUB_CMDLINE_LINUX="").