/var/log/messages,, /var/log/sysloge alguns outros arquivos de log usam um carimbo de data / hora que contém um tempo absoluto, como Jan 13 14:13:10.
/var/log/Xorg.0.loge /var/log/dmesg, assim como a saída de $ dmesg, use um formato parecido com
[50595.991610] malkovich: malkovich malkovich malkovich malkovich
Eu estou supondo / reunindo que os números representam segundos e microssegundos desde a inicialização.
No entanto, minha tentativa de correlacionar esses dois conjuntos de carimbos de data / hora (usando a saída de uptime) deu uma discrepância de cerca de 5000 segundos.
Essa é aproximadamente a quantidade de tempo que meu computador foi suspenso.
Existe uma maneira conveniente de mapear os carimbos de data e hora numéricos usados pelo dmesg e Xorg em carimbos de data e hora absolutos?
atualizar
Como um passo preliminar para descobrir isso, e também para tornar minha pergunta um pouco mais clara, escrevi um script Python para analisar /var/log/sysloge gerar a inclinação do tempo. Na minha máquina, executando o ubuntu 10.10, esse arquivo contém várias linhas originadas pelo kernel, que são carimbadas com o carimbo de data / hora dmesg e o carimbo de data / hora do syslog. O script gera uma linha para cada linha desse arquivo que contém um registro de data e hora do kernel.
Uso:
python syslogdriver.py /var/log/syslog | column -nts $'\t'
Saída expurgada (veja abaixo as definições de coluna):
abs abs_since_boot rel_time rel_offset message
Jan 13 07:49:15 32842.1276569 32842.301498 0 malkovich malkovich
... rel_offseté 0 para todas as linhas intermediárias ...
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_offseté -5280 para todas as linhas 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
... As linhas finais são um pouco mais abaixo, ainda bem acima do final da saída. Presumivelmente, alguns deles foram gravados no dmesgbuffer circular de antes da suspensão ocorrer e foram propagados apenas syslogdepois. Isso explica por que todos eles têm o mesmo registro de data e hora do syslog.
Definições de coluna:
abs é o tempo registrado pelo syslog.
abs_since_booté o mesmo tempo em segundos desde a inicialização do sistema, com base no conteúdo /proc/uptimee no valor de time.time().
rel_time é o registro de data e hora do kernel.
rel_offseté a diferença entre abs_since_boote rel_time. Estou arredondando isso para dezenas de segundos, a fim de evitar erros pontuais devido aos syslogcarimbos de data e hora absolutos ( gerados), apenas com precisão de segundos. Na verdade, essa não é a maneira correta de fazê-lo, pois realmente (eu acho ..) resulta apenas em uma menor chance de ocorrer um erro de 10 por 10. Se alguém tiver uma ideia melhor, entre em contato.
Eu também tenho algumas perguntas sobre o formato de data do syslog; em particular, estou me perguntando se um ano aparece nele. Estou supondo que não, e de qualquer forma provavelmente poderia me ajudar com essas informações no TFM, mas se alguém souber que isso seria útil. .. Supondo, é claro, que alguém use esse script em algum momento no futuro, em vez de apenas interromper algumas linhas do código Perl.
Próximo:
Portanto, a menos que alguma revelação bem-vinda me seja dada por um de vocês, meu próximo passo será adicionar uma função para obter o tempo inclinado para um determinado registro de data e hora do kernel. Deveria poder alimentar um script ou um conjunto de syslogs, juntamente com um carimbo de data / hora do kernel, para obter um carimbo de data / hora absoluto. Depois, posso voltar a depurar meus problemas com o Xorg, que me escapam no momento.
Freezing user space processesque é claramente feito antes do sono.
[12345.6789]..) emitido pelo kernel, por isso está fazendo as coisas corretamente , sujeito aos problemas abordados pelo meu último comentário. Não tenho certeza do que o kernel deveria estar fazendo aqui; depende do que esses registros de data e hora relativos à inicialização devem indicar. O tempo de execução (em oposição ao tempo desde a inicialização) pode ser significativo em alguns contextos. Eu acho que idealmente haveria um registro confiável desses dois valores.
sort, ter ano, fuso horário etc. +1 para o script python.