NTP se está ejecutando, el reloj del sistema aún no está a tiempo, ¿qué da?

Se está ejecutando un servidor estable de Debian (5.0.3) ntpdy conectado a Internet. Aún así, el reloj del sistema está equivocado unos 5 minutos.

$ /etc/init.d/ntp status
NTP server is running..

Partes relevantes (creo) de /etc/ntp.conf:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server 0.europe.pool.ntp.org
server 1.europe.pool.ntp.org
server 2.europe.pool.ntp.org
server 3.europe.pool.ntp.org

Sé que NTP no necesariamente trae el reloj a tiempo inmediatamente. Aún así, ¿cuántas horas o días debe esperar para esperar razonablemente que NTP haya hecho su trabajo y sincronizado el reloj?

¿Me estoy perdiendo algún otro archivo de configuración u opción, o simplemente estoy haciendo algo mal? ¿Es ntp (en lugar de, por ejemplo, ntpdate ) la herramienta adecuada para esto? ¿Hay alguna forma rápida de verificar si la configuración es correcta y si los servidores NTP elegidos devuelven la hora correcta?

Editar : salida de ntpq -pes:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.nexellent.n .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-madrid .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 sinister.wzw.tu .INIT.          16 u    - 1024    0    0.000    0.000   0.000
 dnscache-frankf .INIT.          16 u    - 1024    0    0.000    0.000   0.000

Edición 2 : devuelve el ntpdate -u 0.europe.pool.ntp.orgcomando ( sugerido por brent ) devuelve

17 Dec 17:37:29 ntpdate[14195]: no server suitable for synchronization found

... aunque en otras máquinas ese comando funciona bien. Así que analizaremos la configuración de red / firewall para este servidor en particular (que está en una red diferente, a la que se accede a través de VPN).

Resolución : El culpable no era el firewall local en nuestro servidor, sino la configuración del firewall en algún lugar de la red circundante. Entonces le pedimos al proveedor de alojamiento del servidor que permitiera NTP para nuestras máquinas, y ahora funciona bien. Por ejemplo, ntpq -pahora devuelve:

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 ns1.eunet.fi    192.36.144.23    2 u   10   64    1    1.043    0.258   0.001
 ns2.eunet.fi    62.142.10.44     2 u    9   64    1    0.671    0.135   0.001
 ns3.eunet.fi    62.142.10.44     2 u    8   64    1    0.750    0.277   0.001

(También cambiamos a los servidores eunet.fi recomendados por la empresa de alojamiento, pero eso no viene al caso). Los comandos en la respuesta de brent fueron útiles porque me hicieron darme cuenta de que el problema estaba en el acceso a la red a los servidores NTP, no en la configuración NTP sí mismo. ¡Gracias a todos!

Detenga ntpd, corra ntpdate -u 0.europe.pool.ntp.org3 veces, inicie ntpd, verifique ntpq -p, demore, compense y jitter no debe ser cero.

Si tuviera que adivinar por qué y suponiendo que tenga conectividad de red y pueda ver su host NTP sin problemas, podría ser que haya derivado a un gran valor. Si la diferencia horaria es mayor que X (lo siento, no recuerdo qué X está fuera de lugar), se imprimirá una advertencia y la hora no se sincronizará. Puede consultar sus mensajes de syslog para casos de esto.

Si este es el caso, detenga NTP, ejecute ntpdate host y reinicie el NTPD, esto forzará una sincronización de tiempo y luego comenzará a mantenerla sincronizada en el futuro, si continúa a la deriva, puede tener un problema de hardware.

El hecho de que las columnas de "alcance" sean 0 sugiere que no se pudo hablar con los servidores. Iirc gradualmente se desplazan bits para mostrar cómo fueron los últimos 8 intentos (por lo que 377 es bueno, 0 es malo).