çekirdek önyükleme günlüğü ayrıntı düzeyini azaltma


9

Çekirdeğim önyüklendiğinde, yararlı önemli bilgiler dışında, birçok hata ayıklama bilgisi yazdırır.

....
kernel: [0.00000] BIOS-e820: [mem 0x0000000000000000-0x000000000009d3ff] usable
kernel: [0.00000] BIOS-e820: [mem 0x000000000009d400-0x000000000009ffff] reserved
kernel: [0.00000] BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved
...
kernel: [0.00000] MTRR variable ranges enabled:
kernel: [0.00000]   0 base 0000000000 mask 7E00000000 write-back
...
kernel: [0.00000] init_memory_mapping: [mem 0x00100000-0xcf414fff]
kernel: [0.00000]  [mem 0x00100000-0x001fffff] page 4k
kernel: [0.00000]  [mem 0x00200000-0xcf3fffff] page 2M
kernel: [0.00000]  [mem 0xcf400000-0xcf414fff] page 4k
....
kernel: [0.00000] ACPI: XSDT 0xD8FEB088 0008C (v01 DELL CBX3 01072009 AMI 10013)
kernel: [0.00000] ACPI: FACP 0xD8FFC9F8 0010C (v05 DELL CBX3 01072009 AMI 10013)
....
kernel: [0.00000] Early memory node ranges
kernel: [0.00000]   node   0: [mem 0x00001000-0x0009cfff]
kernel: [0.00000]   node   0: [mem 0x00100000-0xcf414fff]
kernel: [0.00000]   node   0: [mem 0xcf41c000-0xcfdfcfff]
....
kernel: [0.00000] ACPI: Local APIC address 0xfee00000
kernel: [0.00000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
kernel: [0.00000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x02] enabled)

ve çok daha fazlası.

Bunun bir çekirdek geliştirici / hata ayıklayıcı dışında kimse için nasıl yararlı olabileceğini görmüyorum.

loglevel=5Önyükleme parametresi olarak bunlardan kurtulabileceğimi buldum . Hata ayıklama günlükleri artık terminalde yazdırılmaz, ancak yine de içeri dmesgve içeri girer syslog.

O yüzden, global olarak çizme Günlük ayrıntı azaltmak mümkün mü dmesgve syslogbu gereksiz bilgi ile sular altında değil mi?

Kendi derlediğim çekirdeği kullanıyorum 3.18

ETKİLİ ÇÖZÜM

/etc/rsyslog.confBenim için problemi çözmek için aşağıdaki satırları koyarak çıkıyor :

kern.debug   /dev/null
& ~

Çözmeye çalıştığınız gerçek sorunlar nedir? Çok büyük günlük dosyaları mı? Bu bilginin, genellikle insanlar tarafından okunmayan ve boyut artışı önemsiz olan bir günlükte bu konuda bir sorun görmediğimi soruyorum.
Hennes

@Hennes - sorun, bu syslogve dmesgişe yaramaz hata ayıklama günlükleri ile sular altında ve böylece gerçek uyarıları ve hataları göz ardı kolaylaştırır. Ayrıca, dmesgve syslog(yönetici yani) insanlar tarafından okunmalı. Bütün amaçları bu.
Martin Vegter

Su baskını konusunda önemli bilgiler iyi bir noktadır.
Hennes

1
Bu soruyu Superuser Stack-Exchange web sitesinde ilginizi çekebilir: Çekirdek mesajlarının konsoluma taşmasını nasıl
Per15

Yanıtlar:


5

Sistem günlüğü için Aşağıdaki satırı ekleyebilirsiniz /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Çekirdek .info ve .debug mesajlarını silecektir (loglevel = 5 ile silinir)

Ayrıca, belirli loglevel ile mesaj göstermek dmesgiçin seçeneği ile kullanılabilir -n.


4

Bazı günlükler, kapatamadığınız printk () ile yazdırılır . Ve bazıları pr_debug () tarafından basılır, bu da kapatılabilir, çekirdeğin yapılandırmasına bağlıdır. Pr_debug () davranışı dinamik hata ayıklama özelliği tarafından kontrol edilir. Eğer CONFIG_DYNAMIC_DEBUG ayarlanır, sonra tüm pr_debug () çağrıları dinamik olabilir etkin / başına callsite engelli. Dinamik hata ayıklamanın detayı burada . Eğer CONFIG_DYNAMIC_DEBUG ayarlı değil, ancak DEBUG kaynak dosyada tanımlanır, pr_debug () gibi çalışır printk () . Her ikisi de tanımlanmazsa, pr_debug hiçbir şey yapmaz.

İşte çekirdek tanımı:

#include <linux/dynamic_debug.h>

/* If you are writing a driver, please use dev_dbg instead */
#if defined(CONFIG_DYNAMIC_DEBUG)
/* dynamic_pr_debug() uses pr_fmt() internally so we don't need it here */
#define pr_debug(fmt, ...) \
    dynamic_pr_debug(fmt, ##__VA_ARGS__)
#elif defined(DEBUG)
#define pr_debug(fmt, ...) \
    printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#else
#define pr_debug(fmt, ...) \
    no_printk(KERN_DEBUG pr_fmt(fmt), ##__VA_ARGS__)
#endif

Bu nedenle, çekirdek yapılandırmanızı kontrol edin ve bu günlüklerin nereden geldiğini bulun. Sonra nasıl devre dışı bırakacağınızı bileceksiniz.



0

KCL'den ayarlamanın yanı sıra , maksimum seviyeyi istediğinizi yansıtacak ve önyükleme boyunca devam edecek şekilde sysctl ayarını da loglevelyapabilirsiniz .kernel.printk

Yorumdaki bu daha fazla açıklamaya gelince:

sorun şu ki, syslog ve dmesg gereksiz hata ayıklama günlükleriyle dolup taşar ve böylece gerçek uyarıları ve hataları göz ardı etmeyi kolaylaştırır.

logrotateDosyaları yeniden başlattıktan sonra yoldan çıkarmak için sadece bir cron işinde kullanırım :

root ~ $ crontab -l
@reboot /usr/sbin/logrotate --force /root/rotate-boot-messages
@reboot /bin/dmesg -c

root ~ $ cat /root/rotate-boot-messages
"/var/log/dmesg" {
  copytruncate
  notifempty
  missingok
  dateext
}
"/var/log/syslog" {
  copytruncate
  notifempty
  missingok
  dateext
}

Daha sonra, günlüklere sınırlı hata ayıklama verileri dökümü ile, yeni başlıyorsunuz.


Üzgünüm, ama önermek logrotatetamamen özlüyor. Benim sorunum, günlük dosyalarım çok büyük değil ve disk alanı yetersiz olmasıdır. Bunun yerine, sorun, bu günlük dosyalarındaki hata ayıklama bilgilerinin yararlı bilgileri daha az erişilebilir hale getirmesidir.
Martin Vegter

Sağ. Günlüğü tüm bu boktan yolun dışına taşımak için logrotate'i kullanın, böylece önyüklemeden sonra boş bir günlük dosyanız olur, böylece neyin önemli olduğunu görebilirsiniz. Burada logrotate kullanımım kanonik değil: eğer isterseniz mv kullanın. Mesele, önyüklemeden sonra mümkün olan en kısa sürede boktan kurtulmaktır.
fil

Bu mesajlar demek istemediğiniz sürece önyükleme süresi sorunları belirsiz? Bu durumda, kabul edilen çözüm ideal görünüyor.
piskopos
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.