zmniejsz poziom szczegółowości dziennika rozruchu jądra


9

Kiedy moje jądro uruchamia się, oprócz użytecznych ważnych informacji, drukuje wiele informacji o debugowaniu, takich jak

....
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)

i dużo dużo więcej.

Nie rozumiem, jak może to być przydatne dla kogokolwiek innego niż programista / debugger jądra.

Odkryłem, że mogę się ich pozbyć, używając loglevel=5jako parametru rozruchowego. Debugowanie dzienniki nie są drukowane na terminalu, ale są one nadal dmesgw syslog.

Czy to możliwe, aby zmniejszyć szczegółowość dziennika bagażnik na całym świecie, dzięki czemu dmesgi syslognie są zalane przez to niepotrzebnych informacji?

Używam samodzielnie skompilowanego jądra 3.18

AKCEPTOWANE ROZWIĄZANIE

Okazuje się, umieszczając następujące linie, aby /etc/rsyslog.confrozwiązać problem dla mnie:

kern.debug   /dev/null
& ~

Jakie są problemy, które próbujesz rozwiązać? Zbyt duże pliki dziennika? Pytanie, ponieważ nie widzę problemu z posiadaniem tych informacji w dzienniku, który zwykle nie jest odczytywany przez ludzi i którego wzrost rozmiaru jest trywialny.
Hennes,

@Hennes - problemem jest to, że syslogi dmesgsą zalane bezużytecznych dzienników debugowania, a tym samym czyni prawdziwe ostrzeżenia i błędy łatwiej przeoczyć. Poza tym, dmesgi syslogpowinny być odczytywane przez ludzi (czyli administratora). To jest ich cały cel.
Martin Vegter,

Niepokój związany z zalewaniem ważnych informacji jest dobrym punktem.
Hennes,

1
To pytanie może Cię zainteresować na stronie Superuser Stack-Exchange: Jak zatrzymać zalewanie konsoli przez komunikaty jądra?
perror

Odpowiedzi:


5

Dla syslog Możesz dodać następujący wiersz /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Odrzuci wiadomości jądra .info i .debug (które są odrzucane przy pomocy loglevel = 5)

Ponadto dmesgmożna go używać z opcją -nwyświetlania wiadomości z określonym loglevel.


4

Niektóre dzienniki są drukowane przez printk (), którego nie można było wyłączyć. Niektóre są drukowane przez pr_debug (), które mogą być wyłączone w zależności od konfiguracji jądra. Zachowanie pr_debug () jest kontrolowane przez funkcję dynamicznego debugowania. Jeśli ustawiono CONFIG_DYNAMIC_DEBUG , wszystkie wywołania pr_debug () można dynamicznie włączać / wyłączać dla poszczególnych witryn wywołań. Szczegóły dynamicznego debugowania są tutaj . Jeśli CONFIG_DYNAMIC_DEBUG nie jest ustawiony, ale DEBUG jest zdefiniowany w pliku źródłowym, pr_debug () działa jak printk () . Jeśli oba nie są zdefiniowane, pr_debug nic nie zrobi.

Oto definicja w jądrze:

#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

Sprawdź więc konfigurację jądra i dowiedz się, skąd pochodzą te dzienniki. Wtedy będziesz wiedział, jak to wyłączyć.



0

Oprócz ustawiania loglevelKCL, możesz również dostosować kernel.printksysctl, aby maksymalny poziom odzwierciedlał to, co chcesz i utrzymywał się podczas rozruchu.

Co do dalszego wyjaśnienia w komentarzu:

Problem polega na tym, że syslog i dmesg są zalewane bezużytecznymi dziennikami debugowania, dzięki czemu łatwiej jest przeoczyć prawdziwe ostrzeżenia i błędy.

Po prostu logrotateużyłbym w zadaniu crona, aby przenieść pliki z drogi po ponownym uruchomieniu :

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
}

Potem zaczynasz od nowa, że ​​tak powiem, z ograniczonym zrzutem danych debugowania do dzienników.


Przykro mi, ale sugerowanie logrotatecałkowicie mija się z celem. Mój problem nie polega na tym, że moje pliki dziennika są zbyt duże i że brakuje mi miejsca na dysku. Problem polega na tym, że informacje debugujące w tych plikach dziennika sprawiają, że przydatne informacje są mniej dostępne.
Martin Vegter

Dobrze. Użyj logrotate, aby przenieść dziennik ze wszystkimi bzdurami na bok, aby po uruchomieniu rozruchu był pusty plik dziennika, abyś mógł zobaczyć, co się liczy. Moje użycie logrotate tutaj nie jest kanoniczne: użyj mv, jeśli chcesz. Chodzi o to, aby usunąć bzdury tak szybko, jak to możliwe po rozruchu.
biskup

Chyba że masz na myśli, że te komunikaty zaciemniają problemy z czasem uruchamiania? W takim przypadku przyjęte rozwiązanie wydaje się idealne.
biskup
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.