/var/log/messages,, /var/log/sysloget certains autres fichiers journaux utilisent un horodatage qui contient une heure absolue, comme Jan 13 14:13:10.
/var/log/Xorg.0.loget /var/log/dmesg, ainsi que la sortie de $ dmesg, utilisez un format qui ressemble à
[50595.991610] malkovich: malkovich malkovich malkovich malkovich
Je suppose / collecte que les chiffres représentent les secondes et les microsecondes depuis le démarrage.
Cependant, ma tentative de corrélation de ces deux ensembles d'horodatages (en utilisant la sortie de uptime) a donné un écart d'environ 5000 secondes.
C'est à peu près la durée pendant laquelle mon ordinateur a été suspendu.
Existe-t-il un moyen pratique de mapper les horodatages numériques utilisés par dmesg et Xorg en horodatages absolus?
mise à jour
En tant qu'étape préliminaire pour comprendre cela, et aussi pour, espérons-le, clarifier un peu ma question, j'ai écrit un script Python pour analyser /var/log/sysloget produire le décalage temporel. Sur ma machine, exécutant ubuntu 10.10, ce fichier contient de nombreuses lignes d'origine du noyau qui sont estampillées à la fois avec l'horodatage dmesg et l'horodatage syslog. Le script génère une ligne pour chaque ligne de ce fichier qui contient un horodatage du noyau.
Usage:
python syslogdriver.py /var/log/syslog | column -nts $'\t'
Sortie expurgée (voir ci-dessous pour les définitions des colonnes):
abs abs_since_boot rel_time rel_offset message
Jan 13 07:49:15 32842.1276569 32842.301498 0 malkovich malkovich
... rel_offsetvaut 0 pour toutes les lignes intermédiaires ...
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_offsetest -5280 pour toutes les lignes 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
... Les lignes finales sont un peu plus bas, toujours bien au-dessus de la fin de la sortie. Certains d 'entre eux ont probablement été écrits dans dmesgle tampon circulaire d' avant la suspension, et n'ont été propagés syslogqu'après. Cela explique pourquoi tous ont le même horodatage Syslog.
Définitions des colonnes:
abs est le temps enregistré par syslog.
abs_since_bootest la même durée en secondes depuis le démarrage du système, en fonction du contenu /proc/uptimeet de la valeur de time.time().
rel_time est l'horodatage du noyau.
rel_offsetest la différence entre abs_since_bootet rel_time. J'arrondis cela à des dizaines de secondes afin d'éviter les erreurs ponctuelles dues aux sysloghorodatages absolus (c'est-à-dire générés) n'ayant qu'une précision de secondes. En fait, ce n'est pas la bonne façon de le faire, car cela entraîne vraiment (je pense ..) juste une plus petite chance d'avoir une erreur off-by-10. Si quelqu'un a une meilleure idée, faites-le moi savoir.
J'ai également quelques questions sur le format de date de syslog; en particulier, je me demande si une année ne s'y est jamais présentée. Je suppose que non, et dans tous les cas, je pourrais probablement m'aider à ces informations dans TFM, mais si quelqu'un le savait, cela serait utile. .. En supposant, bien sûr, que quelqu'un utilise ce script à un moment donné dans le futur, au lieu de simplement casser quelques lignes de code Perl.
Prochain:
Donc, à moins qu'une révélation bienvenue ne me soit donnée par l'un de vous, ma prochaine étape sera d'ajouter une fonction pour obtenir le décalage temporel pour un horodatage du noyau donné. Je devrais pouvoir alimenter le script un ou un ensemble de syslogs, avec un horodatage du noyau, pour obtenir un horodatage absolu. Ensuite, je peux revenir au débogage de mes problèmes Xorg, qui m'échappent pour le moment.
Freezing user space processesce qui est clairement fait avant de dormir.
[12345.6789]..) émis par le noyau, donc il fait les choses correctement , sous réserve des problèmes traités par mon dernier commentaire. Je ne suis pas sûr de ce que le noyau devrait vraiment faire ici; cela dépend de ce que ces horodatages relatifs au démarrage sont censés indiquer. Le temps d'exécution (par opposition au temps écoulé depuis le démarrage) peut être significatif dans certains contextes. Je suppose que dans l'idéal, il y aurait un enregistrement fiable de ces deux valeurs.
sort, avoir l'année, le fuseau horaire, etc. +1 pour le script python.