-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 El 2007-12-03 a las 09:24 +0100, Camaleón escribió:
El 3/12/07, Carlos E. R. escribió:
No, el reloj local no se puede desactivar nunca, es el principal. Es el reloj del sistema, que se puede consultar cientos de veces por segundo. Eso no se puede hacer con uno de red.
Quería decir que probaras a comentar (desactivar) en /etc/ntpd.conf el reloj indisciplinado para que el demonio ntp no lo use a la hora de sincronizar. Así le fuerzas a usar sólo la sincronización con servidores de tiempo remotos.
El ntp no usa el reloj del sistema para sincronizar. Eso es como mirarte el reloj de la muñeca para poner en hora el reloj de la muñeca - aunque de hecho eso es lo que hace cuando no tiene reloj en la red para no desactivar el código. Es un truco de programador. No lo puedes cambiar y no serviría de nada aunque se hiciera. Es como sacar la manilla al reloj de pulsera para ponerlo en hora, ponerte a dar vueltas a la manilla, y entonces ver que no tienes otro reloj donde mirar la hora para ponerlo en hora. El problema es que el reloj del sistema se desboca y no obedece los cambios de frecuencia que le manda el ntp. O eso o hace saltos, que es lo que yo pienso, que se para porque pierde impulsos o interrupciones. Yo creo que han cambiado algo en el kernel para usar el reloj de otra forma y va mal en determinadas circunstancias.
No creo que tenerlo activado sea obligatorio ¿no? No es el reloj del sistema, y no todo el mundo tiene instalado un servidor de sincronización de tiempo por lo que no lo veo necesario :-?
El reloj del sistema puede ir independiente, que es lo que hemos hecho toda la vida, o se puede ajustar de vez en cuando con otro externo, que es lo que hace el ntp.
Correcto.
No es cuestión de que tenga sentido o no, ese es el reloj del sistema y no se puede cambiar, es central al kernel. A todo kernel de todo ordenador de toda arquitectura... fíjate si hay cosas hechas en común. Si el reloj del sistema no funciona estamos jo... jorobados, eso.
¿Dices que el reloj idisciplinado es el reloj del sistema? :-? No lo entiendo. A ver, ¿no es posible configurar ntp para que use sólo servidores externos? Que ntp no pueda sincronizar la hora no quiere decir que se desajuste el reloj del sistema, vaya, sencillamente tendrá segundos de desfase, pero nada más...
A ver, a ver. Que no tengo problemas con ntp. Tengo problemas con el reloj del sistema, que se para, o algo así, y es el ntp quien se da cuenta. Esto es un ciclo completo del ntp de una de las veces que me falló el reloj. 27 Nov 15:27:20 ntpd[12539]: offset 0.000000 sec freq 82.712 ppm error 0.000001 poll 6 27 Nov 15:27:38 ntpd[12905]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) 27 Nov 15:27:38 ntpd[12905]: peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:38 ntpd[12905]: Deleting interface #2 lo, ::1#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs 27 Nov 15:27:38 ntpd[12905]: Deleting interface #3 eth0, fe80::240:f4ff:fe2e:b121#123, interface stats: received=0, sent=0, dropped=0, active_time=1 secs 27 Nov 15:27:42 ntpd[12905]: peer 91.121... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:44 ntpd[12905]: peer 195.55... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:45 ntpd[12905]: peer 80.33... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:45 ntpd[12905]: peer 217.155... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:45 ntpd[12905]: peer 84.88... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:46 ntpd[12905]: peer 88.191... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:27:46 ntpd[12905]: peer 192.33... event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_reach' (0x8014) 27 Nov 15:30:51 ntpd[12905]: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_local_proto, 2 events, event_restart' (0xc521) 27 Nov 15:30:51 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 15:30:51 ntpd[12905]: kernel time sync status change 0001 27 Nov 15:30:51 ntpd[12905]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_local_proto, 3 events, event_peer/strat_chg' (0x534) 27 Nov 15:30:51 ntpd[12905]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_local_proto, 4 events, event_sync_chg' (0x543) 27 Nov 15:31:56 ntpd[12905]: synchronized to 91.121..., stratum 2 27 Nov 15:38:31 ntpd[12905]: synchronized to 192.33..., stratum 2 27 Nov 15:39:25 ntpd[12905]: synchronized to 195.55..., stratum 2 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 15:39:40 ntpd[12905]: synchronized to LOCAL(0), stratum 10 27 Nov 16:22:22 ntpd[12905]: synchronized to 84.88..., stratum 2 27 Nov 16:22:22 ntpd[12905]: time correction of 1678 seconds exceeds sanity limit (1000); set clock manually to the correct UTC time. 27 Nov 16:22:22 ntpd[12905]: system event 'event_fault' (0x02) status 'leap_none, sync_ntp, 12 events, event_peer/strat_chg' (0x6c4) 27 Nov 17:13:54 ntpd[18877]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010) Tú lo que dices es quitar estas lineas: server 127.127.1.0 # local clock (LCL) fudge 127.127.1.0 stratum 10 # LCL is unsynchronized Creo que las necesita, pero probaré.
Claro está que se pueden tocar los margenes y las velocidades en la configuración, pero ese no es el problema de fondo...
Pues sí que le afecta el tiempo a los sistemas... entiendo que haya problemas con los programas que dependen, pero el sistema "per se" no debería verse afectado de igual forma.
Es por el diseño del unix. En unix el reloj del sistema es un contador que se va incrementando continuamente desde que arranca, con la cuenta marcando los segundos desde noseque dia de que año. Cuando quieres saber la hora humana, haces la conversión. La alteración de ese contador es lo que vuelve locos a los programas. En cambio, si el reloj "humano" fuera independiente del contador, no pasaría nada - que es lo que hace el msdos, al que no le afectan los cambios de hora.
Y si atrasas el reloj ni te cuento.
En algunos casos se pueden colgar las X...
Sí, vale, a los programas sí, eso lo veo normal. Pero que el demonio ntp no pueda sincronizar el reloj del sistema porque tiene un desfase de, por ejemplo, una semana, pues no lo entiendo, para éso precisamente quiero sincronizarlo :-P.
Lo que te dice el ntp es que él no puede cambiarte el reloj de forma lenta porque está demasiado lejos. Si quieres, tú como administrador puedes decirle que lo haga a pesar de todo, aunque tarde dias en ajustarlo. Viene en el manual. En ajustar una hora de retraso puede tardar no recuerdo si es un dia. Si tienes esa paciencia... pero es un dia entero en que el reloj va a estar mal, casi una hora de retraso. Primero una hora, luego 59 minutos, luego 58 minutos, luego 57... y a las nosecuantas horas, ya marcará bien. Vas a tener en los registros todos los eventos marcados a una hora falsa durante un día. Si el desfase es de una semana igual tarda un mes o un año en ponerse al día... no recuerdo cual es la variación admisible, eso está documentado pero no tengo el documento cargado ahora.
Es decir, que los programas se "desbarajusten" debido a los cambios de fecha, entiendo que es problema del administrador, no del demonio ntp ;-).
Pero como los desarrolladores del ntp lo saben, dejan esa decisión al administrador. ¡El fallo que tienen es que no hacen sonar las alarmas! - -- Saludos Carlos E.R. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.4-svn0 (GNU/Linux) iD8DBQFHU/TPtTMYHG2NR9URAjXrAJ0UXOUmhkvRfzQ0uA8/rbK1f9RZYACePY46 XC4v/DWaehgujlOz/e1u3EA= =DNzj -----END PGP SIGNATURE-----