diminuer le niveau de verbosité du journal de démarrage du noyau


9

Lorsque mon noyau démarre, en dehors des informations importantes utiles, il affiche de nombreuses informations de débogage, telles que

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

et bien plus encore.

Je ne vois pas comment cela peut être utile à quelqu'un d'autre qu'un développeur / débogueur de noyau.

J'ai trouvé que je peux m'en débarrasser en utilisant loglevel=5comme paramètre de démarrage. Les journaux de débogage ne sont plus imprimés sur le terminal, mais ils sont toujours dedans dmesget dedans syslog.

Est-il possible de diminuer la verbosité du journal de démarrage globalement, afin que dmesget syslogne soient pas inondés par ces informations inutiles?

J'utilise un noyau auto-compilé 3.18

SOLUTION ACCEPTÉE

Il s'avère que les lignes suivantes ont /etc/rsyslog.confrésolu le problème pour moi:

kern.debug   /dev/null
& ~

Quels sont réellement les problèmes que vous essayez de résoudre? Trop de fichiers journaux? Demander puisque je ne vois aucun problème à avoir ces informations dans un journal qui n'est généralement pas lu par les humains et dont l'augmentation de la taille est triviale.
Hennes

@Hennes - le problème est que sysloget dmesgsont inondés de journaux de débogage inutiles, ce qui rend les avertissements et les erreurs plus faciles à ignorer. En outre, dmesget syslogdoit être lu par les humains (c'est-à-dire l'administrateur). C'est tout leur objectif.
Martin Vegter

La crainte d'inonder des informations importantes est un bon point.
Hennes

1
Vous pouvez être intéressé par cette question sur le site Web du superutilisateur Stack-Exchange: Comment empêcher les messages du noyau d'inonder ma console?
perror

Réponses:


5

Pour syslog Vous pouvez ajouter la ligne suivante à /etc/syslog.conf:

kern.info; kern.debug   /dev/null

Il supprimera les messages .info et .debug du noyau (qui sont supprimés avec loglevel = 5)

En outre, dmesgpeut être utilisé avec option -npour afficher les messages avec certains loglevel.


4

Certains journaux sont imprimés par printk () que vous ne pouvez pas désactiver. Et certains sont imprimés par pr_debug () qui peut être désactivé selon la configuration du noyau. Le comportement de pr_debug () est contrôlé par la fonction de débogage dynamique. Si CONFIG_DYNAMIC_DEBUG est défini, tous les appels pr_debug () peuvent être activés / désactivés dynamiquement par site d'appel. Le détail du débogage dynamique est ici . Si CONFIG_DYNAMIC_DEBUG n'est pas défini, mais DEBUG est défini dans le fichier source, pr_debug () fonctionne comme printk () . Si les deux ne sont pas définis, pr_debug ne fera rien.

Voici la définition dans le noyau:

#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

Vérifiez donc la configuration de votre noyau et découvrez d'où viennent ces journaux. Vous saurez alors comment le désactiver.



0

Outre la configuration loglevelde la KCL, vous pouvez également modifier le kernel.printksysctl afin que le niveau maximum reflète ce que vous voulez et persiste au démarrage.

Concernant cette précision supplémentaire dans le commentaire:

le problème est que syslog et dmesg sont inondés de journaux de débogage inutiles, ce qui rend les avertissements et les erreurs plus faciles à ignorer.

Je voudrais simplement utiliser logrotatedans un travail cron pour déplacer les fichiers après le redémarrage :

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
}

Ensuite, vous commencez frais, pour ainsi dire, avec un vidage limité des données de débogage dans les journaux.


Je suis désolé, mais suggérer est logrotatecomplètement faux. Mon problème n'est pas que mes fichiers journaux sont trop volumineux et que je manque d'espace disque. Au lieu de cela, le problème est que les informations de débogage dans ces fichiers journaux rendent les informations utiles moins accessibles.
Martin Vegter

Droite. Utilisez logrotate pour déplacer le journal avec toutes ces conneries, afin que vous ayez un fichier journal vide après le démarrage, afin que vous puissiez voir ce qui compte. Mon utilisation de logrotate ici n'est pas canonique: utilisez mv si vous le souhaitez. Le but est d'éliminer la merde dès que possible après le démarrage.
évêque

À moins que vous ne vouliez dire que ces messages obscurcissent les problèmes de démarrage? Dans ce cas, la solution acceptée semble idéale.
évêque
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.