Esta tarea trivial surgió en uno de los días viernes y debería haber tomado 2-3 minutos. En general, como siempre.
Un colega me pidió que arreglara el script en su servidor. Lo hizo, se lo entregó y lo dejó caer inadvertidamente: "El tiempo tiene prisa por 5 minutos". Su servidor, incluso si comprende la sincronización. Ha pasado media hora, una hora, y él resopla y jura en voz baja.
"Muddle! - Pensé, cambiando a la consola del servidor, bueno, me iré unos minutos más.
Miramos,
ntp, rdate, sdwdate no
están instalados,
timesyncd está deshabilitado y no se está ejecutando.
# timedatectl Local time: Sun 2019-08-25 20:44:39 +03 Universal time: Sun 2019-08-25 17:44:39 UTC RTC time: Sun 2019-08-25 17:39:52 Time zone: Europe/Minsk (+03, +0300) NTP enabled: no NTP synchronized: no RTC in local TZ: no DST active: n/a
Aquí noto de inmediato que el tiempo de hardware es correcto: será más fácil navegar más allá.
A partir de aquí comenzó una serie de errores.
Primer error Confianza en uno mismo
Klats-klats ...
# systemctl enable systemd-timesyncd.service && systemctl start systemd-timesyncd.service && ntpdate 0.ru.pool.ntp.org && timedatectl set-ntp on && timedatectl 25 Aug 21:00:10 ntpdate[28114]: adjust time server 195.210.189.106 offset -249.015251 sec Local time: Sun 2019-08-25 21:00:10 +03 Universal time: Sun 2019-08-25 18:00:10 UTC RTC time: Sun 2019-08-25 18:00:10 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: n/a
Todo está bien, la hora estaba sincronizada, el sistema coincide con el hardware. "Tómalo", me dejé caer y regresé a mi negocio.
"¿Qué quitas?" - El colega estaba indignado. "¡Los viejos tiempos!"
Cuanto más resuelva problemas típicos, más comenzará su pensamiento y no pensará que la situación número cien o mil sea diferente, pero esta vez no.
# timedatectl Local time: Sun 2019-08-25 21:09:15 +03 Universal time: Sun 2019-08-25 18:09:15 UTC RTC time: Sun 2019-08-25 18:05:04 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a
La hora del sistema es nuevamente incorrecta.
Intentemos de nuevo:
# ntpdate 0.ru.pool.ntp.org && timedatectl && sleep 1 && timedatectl 25 Aug 21:07:37 ntpdate[30350]: step time server 89.175.20.7 offset -249.220828 sec Local time: Sun 2019-08-25 21:07:37 +03 Universal time: Sun 2019-08-25 18:07:37 UTC RTC time: Sun 2019-08-25 18:07:37 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: n/a Local time: Sun 2019-08-25 21:11:46 +03 Universal time: Sun 2019-08-25 18:11:46 UTC RTC time: Sun 2019-08-25 18:07:37 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a
Hagámoslo de manera diferente:
# date -s "2019-08-25 21:10:30" && date && sleep 1 && timedatectl Sun Aug 25 21:10:30 +03 2019 Sun Aug 25 21:10:30 +03 2019 Local time: Sun 2019-08-25 21:14:36 +03 Universal time: Sun 2019-08-25 18:14:36 UTC RTC time: Sun 2019-08-25 18:10:30 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a
Y entonces:
# hwclock --hctosys && timedatectl && sleep 1 && timedatectl Local time: Sun 2019-08-25 21:11:31 +03 Universal time: Sun 2019-08-25 18:11:31 UTC RTC time: Sun 2019-08-25 18:11:31 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: yes RTC in local TZ: no DST active: n/a Local time: Sun 2019-08-25 21:15:36 +03 Universal time: Sun 2019-08-25 18:15:36 UTC RTC time: Sun 2019-08-25 18:11:32 Time zone: Europe/Minsk (+03, +0300) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a
El tiempo se establece por una fracción de segundo, y luego comienza a "apresurarse" nuevamente.
Al mismo tiempo, en los registros, en el momento de dicho cambio manual, solo vemos que el sistema informa que la hora ha cambiado, respectivamente, en la dirección correcta / incorrecta y ocasionalmente
Resincronizando desde systemd-timesyncd.
Aug 25 21:18:51 wisi systemd[1]: Time has been changed Aug 25 21:18:51 wisi systemd-timesyncd[29258]: System time changed. Resyncing. Aug 25 21:18:51 wisi systemd[1187]: Time has been changed Aug 25 21:18:51 wisi systemd[1]: Time has been changed Aug 25 21:18:51 wisi systemd[1187]: Time has been changed
aqui
# ps afx | grep "[1]187" 1187 ? Ss 0:02 /lib/systemd/systemd --user
En este punto, ya era necesario buscar la causa, pero el cerebro durante 18 años de administración ha desarrollado estadísticas de errores de "tiempo" y, por costumbre, nuevamente culpa a la sincronización.
Apágalo completamente.
# timedatectl set-ntp off && systemctl stop systemd-timesyncd.service # hwclock --hctosys && timedatectl && sleep 1 && timedatectl Local time: Sun 2019-08-25 21:25:40 +03 Universal time: Sun 2019-08-25 18:25:40 UTC RTC time: Sun 2019-08-25 18:25:40 Time zone: Europe/Minsk (+03, +0300) NTP enabled: no NTP synchronized: no RTC in local TZ: no DST active: n/a Local time: Sun 2019-08-25 21:29:31 +03 Universal time: Sun 2019-08-25 18:29:31 UTC RTC time: Sun 2019-08-25 18:25:41 Time zone: Europe/Minsk (+03, +0300) NTP enabled: no NTP synchronized: no RTC in local TZ: no DST active: n/a
y en los troncos
Aug 25 21:25:40 wisi systemd[1]: Time has been changed Aug 25 21:25:40 wisi systemd[1187]: Time has been changed Aug 25 21:29:30 wisi systemd[1]: Time has been changed Aug 25 21:29:30 wisi systemd[1187]: Time has been changed
La resincronización se ha ido y el resto de los registros están impecables.
Verificamos las salidas de
tcpdump en el puerto 123 en todas las interfaces. No hay solicitudes, pero el tiempo también se está acabando.
El segundo error. Celeridad
Queda una hora hasta el final de la semana laboral, pero no desea irse el fin de semana con una mala tarea (no preste atención a la hora en el código, el artículo fue escrito en los días siguientes).
Y aquí nuevamente, en lugar de buscar una razón, comencé a tratar de encontrar una explicación para el resultado. Digo "inventar", porque no importa cuán lógicas sean las explicaciones del resultado, este es un enfoque erróneo para resolver el problema.
Este servidor está transmitiendo y convierte la transmisión DVB-S2 a IP. Hay señales de tiempo en la transmisión DVB-S, por lo que los receptores, multiplexores, codificadores y televisores a menudo las usan para sincronizar el reloj del sistema. Los controladores para las placas DVB-S se compilan en el núcleo, por lo que la forma más rápida de garantizar un flujo DVB-S2 limpio es desconectar los cables que provienen de las "placas". Afortunadamente, el servidor está detrás de la pared, por lo tanto, que así sea.
Por supuesto, si los registros tuvieran lo que debería estar allí, esto no habría sucedido, pero más sobre eso, nuevamente, al final del artículo.
Bueno, dado que ya hemos eliminado todas las señales de satélite, también eliminaremos las terrestres, a lo largo del camino retiramos todos los cables de red. El servidor se desconecta del mundo exterior y funciona de manera completamente autónoma, pero el reloj del sistema todavía tiene prisa.
La semana laboral ha terminado, y la cuestión de la fecha / hora no es crítica, así que puedes irte a casa, pero aquí cometo un nuevo error.
El tercer error. Asesores
Nunca! Nunca haga preguntas en foros y sitios generalmente especializados (a la stackoverflow) si la respuesta requiere más que estudiar la emisión de la primera página de Google y leer una página de man'a.
Será enviado de vuelta a Google, leerá al mismo hombre y explicará popularmente las reglas del foro / sitio, pero no dará una respuesta.
Hay dos factores objetivos:
- nadie, excepto usted, también puede conocer el problema;
- nadie puede probar en las mismas condiciones que usted
y subjetivo:
- es posible que no proporcione todas las entradas para resolver el problema, porque ya ha encontrado la dirección "correcta" y ha establecido la esencia del problema al descansar en él;
- el capataz (moderador, veterano, administrador) siempre tiene razón si el capataz está equivocado ... bueno, ya sabes ...
Si en respuesta a los comentarios permaneció dentro del marco del vocabulario de censura, entonces tiene nervios fuertes.
Solución
No es necesario dividir las tareas en simples y complejas.
Dejamos de depender de nuestra experiencia, estadísticas, asesores y comenzamos a no "explicar" el resultado final, sino a buscar constantemente la razón.
Una vez que alguien establece la hora, se debe realizar una llamada al sistema adecuada.
Como en la documentación del software, los mejores muelles son las fuentes, por lo que en la administración del sistema el mejor asistente es la auditoría, en nuestro caso
auditada .
Momento de dudaMe encontré con el hombre, pero no estaba completamente seguro de que el reloj en Linux solo se puede configurar por
clock_settime y
settimeofday , por lo que para la primera prueba seleccioné todas las llamadas "adecuadas":
# man syscalls | col | grep -F '(2)' | grep -vE '(:|;)' | grep -E '(time|date|clock)' | sed "s/(2).*//" | xargs -I SYSCALL echo "-S SYSCALL " | xargs echo -S adjtimex -S clock_adjtime -S clock_getres -S clock_gettime -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S s390_runtime_instr -S setitimer -S settimeofday -S stime -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_create -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimes
y descartando
s390_runtime_instr, stime, timerfd_create , que
auditctl no reconoció, inicialmente comenzó la auditoría en la forma:
auditctl -a exit,always -S adjtimex -S clock_adjtime -S clock_getres -S clock_nanosleep -S clock_settime -S futimesat -S getitimer -S gettimeofday -S mq_timedreceive -S mq_timedsend -S rt_sigtimedwait -S semtimedop -S setitimer -S settimeofday -S time -S timer_create -S timer_delete -S timer_getoverrun -S timer_gettime -S timer_settime -S timerfd_gettime -S timerfd_settime -S times -S utime -S utimensat -S utimes
Después de asegurarme de que en los lugares de los registros que me interesan, no hay otros
syscalls que no sean estos dos, entonces solo los utilicé.
Comenzamos la auditoría de las llamadas del sistema
clock_settime y
settimeofday e intentamos cambiar la fecha:
# auditctl -a exit,always -S clock_settime -S settimeofday && date -s "2019-08-22 12:10:00" && sleep 5 && auditctl -D
Se ha agregado una demora de cinco segundos para que nuestro "parásito" corrija la hora.
Nos fijamos en el informe:
# aureport -s -i Syscall Report ======================================= # date time syscall pid comm auid event ======================================= Warning - freq is non-zero and incremental flushing not selected. 1. 08/22/2019 12:10:00 settimeofday 3088 chkcache_proces root 479630 2. 08/26/2019 09:37:06 clock_settime 1538 date root 479629
Aquí vemos nuestra
fecha y desconocida para nosotros
chkcache_proces . Resultó estar en el informe anterior, ya que aureport ordenó la salida por fecha al convertir desde la vista binaria, y el evento ocurrió en el momento en que configuramos la
fecha -s "2019-08-22 12:10:00" .
¿Quién lo dio a luz?
# ausearch -sc settimeofday --comm "chkcache_proces" ---- time->Thu Aug 22 12:10:00 2019 type=PROCTITLE msg=audit(1566465000.000:479630): proctitle="/usr/local/bin/oscam" type=SYSCALL msg=audit(1566465000.000:479630): arch=c000003e syscall=164 success=yes exit=0 a0=7fde0dfc6e60 a1=0 a2=136cf a3=713ba56 items=0 ppid=3081 pid=3088 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 tty=pts20 ses=68149 comm="chkcache_proces" exe="/usr/local/bin/oscam" key=(null)
/ usr / local / bin / oscam : se encontró nuestro parásito. A pesar de su comportamiento "malicioso", es imposible abandonar el sistema de acceso condicional, pero aún así me gustaría saber,
oscam , WTF?
La respuesta se encuentra rápidamente en la
fuente :
#if defined(CLOCKFIX) if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec))
Qué lindo se ve la línea de
advertencia comentada aquí ...