/ Var / log / * zaman damgalarını ilişkilendirme

/var/log/messages, /var/log/syslogve diğer bazı günlük dosyaları, mutlak zaman içeren bir zaman damgası kullanır Jan 13 14:13:10.

/var/log/Xorg.0.logve /var/log/dmesgyanı çıktısı olarak $ dmesg, bir biçim kullandığını görünüyor gibi

[50595.991610] malkovich: malkovich malkovich malkovich malkovich

Sanırım sayıların başlangıçtan bu yana saniye ve mikrosaniyeyi temsil ettiğini düşünüyorum.

Ancak, bu iki zaman damgası kümesini ilişkilendirme girişimim (çıktısını kullanarak uptime) yaklaşık 5000 saniyelik bir tutarsızlık verdi.

Bu kabaca bilgisayarımın askıya alınma süresidir.

Dmesg ve Xorg tarafından kullanılan sayısal zaman damgalarını mutlak zaman damgalarına eşlemek için uygun bir yol var mı?

Güncelleme

Bunu anlamaya yönelik bir ön adım olarak ve umarım sorumu biraz daha açık hale getirmek için , zaman eğriliğini ayrıştırmak ve çıktılamak için bir Python betiği yazdım /var/log/syslog. Benim makinemde ubuntu 10.10 çalıştıran bu dosya, hem dmesg zaman damgası hem de syslog zaman damgası ile damgalanmış çok sayıda çekirdek kaynaklı satır içeriyor. Komut dosyası, dosyadaki her satır için bir çekirdek zaman damgası içeren bir satır verir.

Kullanımı:

python syslogdriver.py /var/log/syslog | column -nts $'\t'

Çıkarılan çıktı (sütun tanımları için aşağıya bakın):

abs              abs_since_boot  rel_time      rel_offset  message
Jan 13 07:49:15  32842.1276569   32842.301498  0           malkovich malkovich

... rel_offsetaraya giren tüm hatlar için 0'dır ...

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_offsetkalan tüm satırlar için -5280'dir ...

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

... Son çizgiler biraz daha aşağıdan, yine de çıktı sonunun çok üstünde. Bazıları muhtemelen dmesgaskıya alınmadan önce dairesel tampon belleğe yazılmıştır ve sadece syslogdaha sonra yayılmıştır . Bu, hepsinin neden aynı syslog zaman damgasına sahip olduğunu açıklar.

Sütun tanımları:

abs syslog tarafından kaydedilen zamandır.

abs_since_bootiçeriği /proc/uptimeve değerine bağlı olarak, sistemin başlatılmasından bu yana geçen saniye cinsinden süredir time.time().

rel_time çekirdek zaman damgasıdır.

rel_offsetabs_since_bootve arasındaki farktır rel_time. syslogSadece saniye hassasiyetine sahip mutlak (yani- oluşturulmuş) zaman damgaları nedeniyle bir kerelik hataları önlemek için bu onlarca saniye yuvarlama . Aslında bunu yapmanın doğru yolu bu değil, çünkü gerçekten (sanırım ..) sadece 10 hataya neden olma şansının azalmasıyla sonuçlanıyor. Birinin daha iyi bir fikri varsa, lütfen bana bildirin.

Ayrıca syslog'un tarih biçimi hakkında bazı sorularım var; özellikle, bir yılın içinde ortaya çıkıp çıkmadığını merak ediyorum. Hayır, tahmin etmiyorum ve her durumda TFM'deki bu bilgiler konusunda kendime yardımcı olabilirim, ancak biri bilirse yararlı olur. Tabii ki, birinin sadece birkaç satır Perl kodunu patlatmak yerine, bu komut dosyasını gelecekte bir noktada kullandığını varsayalım.

Sonraki:

Bu yüzden, sizden biri tarafından bana hoşgeldin vahiyi verilmedikçe, bir sonraki adımım, belirli bir çekirdek zaman damgası için zaman eğriltmesi için bir işlev eklemek olacaktır. Mutlak bir zaman damgası almak için komut dosyasını bir veya bir dizi syslog dosyasını, bir çekirdek zaman damgasıyla birlikte besleyebilmeliyim. Sonra Xorg sorunlarımı hata ayıklamaya geri dönebilirim.

İlginç bir sorun, Bunu yapmaya çalıştığımdan emin değilim. Ama bahsettiğiniz zaman damgasını fark ettim ve açılıştan bu yana her zaman saniyeler olduğuna inanıyorum.

Sistem günlüğümde sunucumda var:

Jan 10 19:58:55 wdgitial kernel: [    0.000000] Initializing cgroup subsys cpuset
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Initializing cgroup subsys cpu
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Linux version 2.6.32-21-server (buildd@yellow) (gcc version 4.4.3 (Ubuntu 4.4.3-4ubuntu5) ) #32-Ubuntu SMP Fri Apr 16     09:17:34 UTC 2010 (Ubuntu 2.6.32-21.32-server 2.6.32.11+drm33.2)
Jan 10 19:58:55 wdgitial kernel: [    0.000000] Command line:  root=/dev/xvda1 ro quiet splash

Bunun çoğu Linux dağıtımı arasında oldukça tutarlı olduğunu düşünürüm, çünkü bu, onun tükürdüğü çekirdek.

Ve burada zaman damgası ile birlikte bir tarih var.

Bunu deneyebilirsiniz:

İlk olarak, dmesg dosyasının zaman damgasını alın (varsayım bu dmesg'in zamanı 0 olacaktır). Kullanacaksın

ls -l --zaman tarzı = +% s

/var/log$ ls -l --time-style=+%s dmesg
-rw-r----- 1 root adm 56181 1294941018 dmesg

Saniyeyi okunabilir bir tarihe dönüştürebilirsiniz.

perl -e 'print scalar localtime(1294941018)' 

Okunabilir bir olay zamanı görmek için dmesg'deki olaydan saniye cinsini ekleyin. Dmesg olayı 55.290387 saniye ise, 55 veya 55.290387 ekleyin:

perl -e 'print scalar localtime(1294953978 + 55)'

Epochal-rooted saniyeleri okunabilir zamana dönüştürmenin başka bir yolu da --d tarihini önerildiği gibi kullanmaktır. -D ile sağlanan bir zamanı temsil etmek için 'tarih' yazarsanız, dönüştürülecek sürenin @ ile dönemden bu yana saniye cinsinden olduğunu belirtebilirsiniz.

date -d "@1294953978"

Bu size çıktı olarak "Per Jan 13 15:26:18 CST 2011" gibi bir şey verir.

tarih +% s

Kabuk matematik nasıl hatırlayamıyorum, bu yüzden genellikle yukarıdaki gibi perl yöntemini kullanın. :)

Numarayı dmesg'den bir tarihe eşleştirmenin en kolay yolu dateprogramı kullanmaktır .

date -d "-50595 seconds"

Bu komut geçerli zamanın eksi 50595 saniye tarihini görüntüler.

Gönderen man date:

-d, --date=STRING
       display time described by STRING, not `now'

Sayı, açılış zamanından bu yana geçen süreye değil, açılış süresine eşittir.

Askıya alma / devam ettirme sırasında eğriltme zamanının değiştiğini belirttiğiniz için, bunun en az bir yerde belgelendiğini not edeceğim. Dmesg (1) kılavuz sayfası:

Günlükler için kullanılan zaman kaynağı SUSPEND / RESUME sisteminden sonra güncellenmez.

Çekirdeğin bu zaman damgalarını duvar zamanı ile senkronize etmesini sağlamanın bir yolunu bulamadım.

Çabuk, kirli, çalışıyor.

$ dmesg | grep 3w | perl /root/print_time_offset.pl

Bu komut dosyasının içeriği:

$ cat /root/print_time_offset.pl

#!/usr/bin/perl

$uptime = `cat /proc/uptime | awk '{print $1}';`;
$boot = time() - $uptime;
chomp $boot;
while (<STDIN>) {
        if ($_ =~ /^\[([\s\d\.]+)\]/) {
                $time_offset = $1;
        }
        $real_time = sprintf scalar localtime($boot + $time_offset);
        $_ =~ s/\[[\s\d\.]+\]/\[$real_time\]/;
        print $_;
}

Örnek çıktı aşağıdaki gibidir:

[Mon Feb 21 23:06:33 2011] 3ware 9000 Storage Controller device driver for Linux v2.26.02.012.
[Mon Feb 21 23:06:33 2011] 3w-9xxx 0000:03:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
[Mon Feb 21 23:06:33 2011] 3w-9xxx 0000:03:00.0: setting latency timer to 64
[Mon Feb 21 23:06:33 2011] scsi4 : 3ware 9000 Storage Controller
[Mon Feb 21 23:06:33 2011] 3w-9xxx: scsi4: Found a 3ware 9000 Storage Controller at 0xfbcde000, IRQ: 16.
[Mon Feb 21 23:06:34 2011] 3w-9xxx: scsi4: Firmware FE9X 4.08.00.006, BIOS BE9X 4.08.00.001, Ports: 4.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Mon Feb 21 23:06:35 2011] 3w-9xxx: scsi4: ERROR: (0x03:0x0101): Invalid command opcode:opcode=0x85.
[Sat Feb 26 02:01:01 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Feb 26 02:01:01 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
[Sat Feb 26 16:49:13 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=1.
[Sat Feb 26 17:07:19 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=0.
[Sat Mar  5 02:00:16 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Mar  5 02:00:16 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.
[Sat Mar  5 18:48:57 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=1.
[Sat Mar  5 19:05:17 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x002B): Verify completed:unit=0, subunit=0.
[Sat Mar 12 02:00:30 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=1.
[Sat Mar 12 02:00:30 2011] 3w-9xxx: scsi4: AEN: INFO (0x04:0x0029): Verify started:unit=0, subunit=0.