/var/log/messages, /var/log/syslogy algunos otros archivos de registro usan una marca de tiempo que contiene un tiempo absoluto, como Jan 13 14:13:10.
/var/log/Xorg.0.logy /var/log/dmesg, además de la salida de $ dmesg, use un formato que se vea como
[50595.991610] malkovich: malkovich malkovich malkovich malkovich
Supongo que los números representan segundos y microsegundos desde el inicio.
Sin embargo, mi intento de correlacionar estos dos conjuntos de marcas de tiempo (usando la salida de uptime) dio una discrepancia de aproximadamente 5000 segundos.
Esta es aproximadamente la cantidad de tiempo que mi computadora estuvo suspendida.
¿Hay una manera conveniente de asignar las marcas de tiempo numéricas utilizadas por dmesg y Xorg en marcas de tiempo absolutas?
actualizar
Como un paso preliminar para resolver esto, y también para que mi pregunta sea un poco más clara, he escrito un script de Python para analizar /var/log/syslogy generar el sesgo de tiempo. En mi máquina, ejecutando ubuntu 10.10, ese archivo contiene numerosas líneas originadas en el núcleo que están estampadas con la marca de tiempo dmesg y la marca de tiempo syslog. El script genera una línea para cada línea en ese archivo que contiene una marca de tiempo del núcleo.
Uso:
python syslogdriver.py /var/log/syslog | column -nts $'\t'
Salida expurgada (ver abajo para las definiciones de columna):
abs abs_since_boot rel_time rel_offset message
Jan 13 07:49:15 32842.1276569 32842.301498 0 malkovich malkovich
... rel_offsetes 0 para todas las líneas intermedias ...
Jan 13 09:55:14 40401.1276569 40401.306386 0 PM: Syncing filesystems ... done.
Jan 13 09:55:14 40401.1276569 40401.347469 0 PM: Preparing system for mem sleep
Jan 13 11:23:21 45688.1276569 40402.128198 -5280 Skipping EDID probe due to cached edid
Jan 13 11:23:21 45688.1276569 40402.729152 -5280 Freezing user space processes ... (elapsed 0.03 seconds) done.
Jan 13 11:23:21 45688.1276569 40402.760110 -5280 Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jan 13 11:23:21 45688.1276569 40402.776102 -5280 PM: Entering mem sleep
... rel_offsetes -5280 para todas las líneas restantes ...
Jan 13 11:23:21 45688.1276569 40403.149074 -5280 ACPI: Preparing to enter system sleep state S3
Jan 13 11:23:21 45688.1276569 40403.149477 -5280 PM: Saving platform NVS memory
Jan 13 11:23:21 45688.1276569 40403.149495 -5280 Disabling non-boot CPUs ...
Jan 13 11:23:21 45688.1276569 40403.149495 -5280 Back to C!
Jan 13 11:23:21 45688.1276569 40403.149495 -5280 PM: Restoring platform NVS memory
Jan 13 11:23:21 45688.1276569 40403.151034 -5280 ACPI: Waking up from system sleep state S3
... Las líneas finales son un poco más abajo, aún muy por encima del final de la salida. Algunos de ellos presumiblemente se escribieron en dmesgel búfer circular antes de que ocurriera la suspensión, y solo se propagaron syslogdespués. Esto explica por qué todos ellos tienen la misma marca de tiempo de syslog.
Definiciones de columna:
abs es el tiempo registrado por syslog.
abs_since_bootes el mismo tiempo en segundos desde el inicio del sistema, basado en el contenido /proc/uptimey el valor de time.time().
rel_time es la marca de tiempo del kernel.
rel_offsetes la diferencia entre abs_since_booty rel_time. Estoy redondeando esto a las decenas de segundos para evitar errores syslogúnicos debido a que las marcas de tiempo absolutas (es decir, generadas) solo tienen precisión de segundos. En realidad, esa no es la forma correcta de hacerlo, ya que realmente (creo que ...) solo da como resultado una menor posibilidad de tener un error de 10 por 10. Si alguien tiene una idea mejor, hágamelo saber.
También tengo algunas preguntas sobre el formato de fecha de syslog; en particular, me pregunto si alguna vez aparece un año en él. Supongo que no, y en cualquier caso probablemente podría ayudarme a mí mismo con esa información en TFM, pero si alguien sabe que sería útil. Suponiendo, por supuesto, que alguien use este script en algún momento en el futuro, en lugar de simplemente romper un par de líneas de código Perl.
Próximo:
Por lo tanto, a menos que una de ustedes me dé una revelación bienvenida, mi próximo paso será agregar una función para obtener el sesgo de tiempo para una marca de tiempo del núcleo dado. Debería poder alimentar el script uno o un conjunto de syslogs, junto con una marca de tiempo del núcleo, para obtener una marca de tiempo absoluta. Entonces puedo volver a depurar mis problemas de Xorg, que se me escapan en este momento.
Freezing user space processescual se hace claramente antes de dormir.
[12345.6789]..) emitido por el núcleo, por lo que está haciendo las cosas correctamente , sujeto a los problemas abordados por mi último comentario. No estoy seguro de qué debería hacer realmente el núcleo aquí; depende de lo que esas marcas de tiempo relativas al inicio están destinadas a indicar. El tiempo de ejecución (en oposición al tiempo desde el arranque) puede ser significativo en algunos contextos. Supongo que idealmente habría un registro confiable de ambos valores.
sort, tener año, zona horaria, etc. +1 para el script de Python.