/var/log/messages,, /var/log/syslogdan beberapa file log lainnya menggunakan stempel waktu yang berisi waktu absolut, seperti Jan 13 14:13:10.
/var/log/Xorg.0.logdan /var/log/dmesg, serta output dari $ dmesg, gunakan format yang terlihat seperti
[50595.991610] malkovich: malkovich malkovich malkovich malkovich
Saya menduga / mengumpulkan bahwa angka mewakili detik dan mikrodetik sejak startup.
Namun, upaya saya untuk mengkorelasikan dua set cap waktu ini (menggunakan output dari uptime) memberikan perbedaan sekitar 5000 detik.
Ini kira-kira jumlah waktu komputer saya diskors.
Apakah ada cara mudah untuk memetakan cap waktu numerik yang digunakan oleh dmesg dan Xorg menjadi cap waktu absolut?
memperbarui
Sebagai langkah awal menuju penyelesaian masalah ini, dan juga semoga membuat pertanyaan saya sedikit lebih jelas, saya telah menulis skrip Python untuk mengurai /var/log/syslogdan menampilkan waktu yang miring. Di komputer saya, menjalankan ubuntu 10.10, file itu berisi banyak baris yang berasal dari kernel yang dicap baik dengan stempel waktu dmesg dan stempel waktu syslog. Script menampilkan baris untuk setiap baris dalam file yang berisi cap waktu kernel.
Pemakaian:
python syslogdriver.py /var/log/syslog | column -nts $'\t'
Output yang dihapuskan (lihat di bawah untuk definisi kolom):
abs abs_since_boot rel_time rel_offset message
Jan 13 07:49:15 32842.1276569 32842.301498 0 malkovich malkovich
... rel_offsetadalah 0 untuk semua jalur intervensi ...
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_offsetadalah -5280 untuk semua saluran yang tersisa ...
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
... Baris terakhir dari sedikit lebih jauh ke bawah, masih jauh di atas akhir output. Beberapa dari mereka mungkin ditulis ke dmesgbuffer bundar sebelum penangguhan terjadi, dan hanya diperbanyak syslogsetelah itu. Ini menjelaskan mengapa mereka semua memiliki stempel waktu syslog yang sama.
Definisi kolom:
abs adalah waktu dicatat oleh syslog.
abs_since_bootadalah waktu yang sama dalam hitungan detik sejak startup sistem, berdasarkan pada isi /proc/uptimedan nilai time.time().
rel_time adalah cap waktu kernel.
rel_offsetperbedaan antara abs_since_bootdan rel_time. Saya membulatkan ini ke puluhan detik untuk menghindari kesalahan satu kali karena syslogcap waktu absolut (yaitu yang dihasilkan) hanya memiliki ketepatan detik. Itu sebenarnya bukan cara yang tepat untuk melakukannya, karena itu benar-benar (saya pikir ..) hanya menghasilkan peluang lebih kecil untuk memiliki kesalahan off-by-10. Jika seseorang memiliki ide yang lebih baik, beri tahu saya.
Saya juga memiliki beberapa pertanyaan tentang format tanggal syslog; khususnya, saya bertanya-tanya apakah setahun pernah muncul di dalamnya. Saya kira tidak, dan dalam hal apa pun kemungkinan besar bisa membantu diri saya sendiri untuk informasi itu di TFM, tetapi jika seseorang mengetahui hal itu akan berguna. ..Menganggap, tentu saja, bahwa seseorang menggunakan skrip ini di beberapa titik di masa depan, bukan hanya menerobos beberapa baris kode Perl.
Berikutnya:
Jadi, kecuali jika beberapa sambutan selamat datang kepada saya diberikan oleh salah satu dari Anda, langkah saya berikutnya adalah menambahkan fungsi untuk mendapatkan waktu yang miring untuk cap waktu kernel yang diberikan. Saya seharusnya dapat memberi makan script satu atau satu set syslog, bersama dengan cap waktu kernel, untuk mendapatkan cap waktu absolut. Lalu saya bisa kembali ke debugging masalah Xorg saya, yang melarikan diri saya saat ini.
Freezing user space processesyang jelas dilakukan sebelum tidur.
[12345.6789]..) yang dipancarkan oleh kernel, sehingga ia melakukan hal-hal dengan benar , tunduk pada masalah yang dibahas oleh komentar terakhir saya. Saya tidak yakin apa yang seharusnya dilakukan kernel di sini; itu tergantung pada apa cap waktu relatif startup yang dimaksudkan untuk menunjukkan. Waktu berjalan (sebagai lawan dari waktu sejak boot) mungkin bermakna dalam beberapa konteks. Saya kira idealnya akan ada catatan yang dapat diandalkan dari kedua nilai tersebut.
sort, memiliki tahun, zona waktu, dll. +1 untuk skrip python.