/var/log/messages, /var/log/sysloge alcuni altri file di registro utilizzano un timestamp che contiene un tempo assoluto, come Jan 13 14:13:10.
/var/log/Xorg.0.loge /var/log/dmesg, oltre all'output di $ dmesg, utilizzare un formato simile
[50595.991610] malkovich: malkovich malkovich malkovich malkovich
Sto indovinando / raccogliendo che i numeri rappresentano secondi e microsecondi dall'avvio.
Tuttavia, il mio tentativo di correlare questi due set di timestamp (usando l'output di uptime) ha prodotto una discrepanza di circa 5000 secondi.
Questo è approssimativamente il periodo di tempo in cui il mio computer è stato sospeso.
C'è un modo conveniente per mappare i timestamp numerici usati da dmesg e Xorg in timestamp assoluti?
aggiornare
Come passo preliminare per capire questo, e anche per spero di rendere la mia domanda un po 'più chiara, ho scritto uno script Python per analizzare /var/log/sysloge produrre l'inclinazione del tempo. Sul mio computer, con Ubuntu 10.10, quel file contiene numerose linee originate dal kernel che sono stampate sia con il timestamp dmesg che con il timestamp syslog. Lo script genera una riga per ogni riga in quel file che contiene un timestamp del kernel.
Uso:
python syslogdriver.py /var/log/syslog | column -nts $'\t'
Output espurgato (vedi sotto per le definizioni delle colonne):
abs abs_since_boot rel_time rel_offset message
Jan 13 07:49:15 32842.1276569 32842.301498 0 malkovich malkovich
... rel_offsetè 0 per tutte le linee intermedie ...
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 per tutte le linee rimanenti ...
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
... Le linee finali sono un po 'più in basso, ancora ben al di sopra della fine dell'output. Alcuni di loro presumibilmente dmesgfurono scritti nel buffer circolare prima che la sospensione avvenisse, e furono propagati solo in syslogseguito. Questo spiega perché tutti hanno lo stesso timestamp syslog.
Definizioni delle colonne:
abs è il tempo registrato da syslog.
abs_since_bootè lo stesso tempo in secondi dall'avvio del sistema, basato sul contenuto /proc/uptimee sul valore di time.time().
rel_time è il timestamp del kernel.
rel_offsetè la differenza tra abs_since_boote rel_time. Sto arrotondando questo a decine di secondi in modo da evitare errori una tantum dovuti ai syslogtimestamp assoluti (cioè generati) che hanno solo la precisione dei secondi. Questo non è in realtà il modo giusto di farlo, dal momento che (credo ...) si traduce in una minore possibilità di avere un errore off-by-10. Se qualcuno ha un'idea migliore, per favore fatemi sapere.
Ho anche alcune domande sul formato della data di syslog; in particolare, mi chiedo se mai un anno ci si presenta. Immagino di no, e in ogni caso potrebbe molto probabilmente aiutarmi a ottenere tali informazioni in TFM, ma se qualcuno capisse che sarebbe utile. ..Supponendo, ovviamente, che qualcuno userà questo script ad un certo punto in futuro, invece di eliminare solo un paio di righe di codice Perl.
Il prossimo:
Quindi, a meno che una rivelazione di benvenuto non mi sia stata data da uno di voi, il mio prossimo passo sarà quello di aggiungere una funzione per ottenere il tempo distorto per un dato timestamp del kernel. Dovrei essere in grado di alimentare lo script uno o un insieme di syslog, insieme a un timestamp del kernel, per ottenere un timestamp assoluto. Quindi posso tornare al debug dei miei problemi con Xorg, che al momento mi sfuggono.
Freezing user space processesquali è chiaramente fatto prima di dormire.
[12345.6789]..) emesso dal kernel, quindi sta facendo le cose correttamente , fatti salvi i problemi risolti dal mio ultimo commento. Non sono sicuro di cosa dovrebbe fare davvero il kernel qui; dipende da cosa indicano quei timestamp relativi all'avvio. Il tempo di esecuzione (al contrario del tempo trascorso dall'avvio) può essere significativo in alcuni contesti. Immagino idealmente che ci sarebbe una registrazione affidabile di entrambi questi valori.
sort, avere anno, fuso orario, ecc. +1 per lo script Python.