カーネルブートログの詳細レベルを下げる

カーネルが起動すると、役立つ重要な情報の他に、次のような多くのデバッグ情報が出力されます。

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

そしてはるかに。

これがカーネル開発者/デバッガ以外の人にどのように役立つかはわかりません。

loglevel=5ブートパラメータとして使用することで、これらを取り除くことができることがわかりました。デバッグログは端末に出力されなくなりましたが、まだdmesgとにありsyslogます。

それはように、世界的に起動ログの冗長性を減少させることが可能であるdmesgとsyslog、この役に立たない情報であふれませんか？

自己コンパイルされたカーネルを使用しています 3.18

受け入れられているソリューション

結局/etc/rsyslog.conf、私のために問題を解決するために次の行を入れます：

kern.debug   /dev/null
& ~

syslogの場合次の行をに追加できます/etc/syslog.conf。

kern.info; kern.debug   /dev/null

カーネルの.infoおよび.debugメッセージを破棄します（これらはloglevel = 5で破棄されます）

また、特定のログレベルのメッセージを表示するdmesgオプションとともに使用できます-n。

一部のログは、オフにできなかったprintk（）によって出力されます。そして、いくつかは、カーネルの設定に依存してオフにされるかもしれないpr_debug（）によって出力されます。pr_debug（）の動作は、動的デバッグ機能によって制御されます。場合CONFIG_DYNAMIC_DEBUGがセットされ、その後、すべてのpr_debug（）の呼び出しは、動的/ごとの呼び出し場所有効または無効にすることができます。動的デバッグの詳細はこちらです。場合CONFIG_DYNAMIC_DEBUGが設定されていませんが、DEBUGは、ソースファイルで定義され、pr_debugは（）のように働くのprintk（） 。両方が定義されていない場合、pr_debugは何もしません。

カーネルでの定義は次のとおりです。

#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

そのため、カーネル構成を確認し、これらのログがどこから来たかを確認してください。次に、それを無効にする方法を知っています。

loglevelKCLからを設定する以外に、kernel.printksysctlを微調整して、最大レベルが必要なものを反映し、ブート全体で維持されるようにすることもできます。

これについてのコメントでのさらなる明確化について：

問題は、syslogとdmesgが役に立たないデバッグログであふれているため、実際の警告とエラーを見落としやすくなることです。

再起動logrotate後にファイルを移動するために、cronジョブで使用するだけです。

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
}

次に、いわば、ログへのデバッグデータのダンプが制限された状態で、新たに始めます。