ลดระดับการบันทึกล็อกเคอร์เนลของเคอร์เนล

9

เมื่อเคอร์เนลของฉันบูทนอกเหนือจากข้อมูลสำคัญที่มีประโยชน์มันจะพิมพ์ข้อมูลการดีบักจำนวนมากเช่น

....
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เป็นพารามิเตอร์การบูต บันทึกการแก้จุดบกพร่องจะไม่พิมพ์บน terminal, แต่พวกเขายังคงอยู่ในและในdmesgsyslog

เป็นไปได้หรือไม่ที่จะลดการฟุ่มล็อกบันทึกการบูตทั่วโลกเพื่อให้dmesgและsyslogไม่ถูกน้ำท่วมโดยข้อมูลที่ไร้ประโยชน์นี้?

ฉันใช้เคอร์เนลที่คอมไพล์ด้วยตนเอง 3.18

โซลูชั่นที่ได้รับการยอมรับ

ปรากฎวางบรรทัดต่อไปนี้เพื่อ/etc/rsyslog.confแก้ไขปัญหาสำหรับฉัน:

kern.debug   /dev/null
& ~

— Martin Vegter
แหล่งที่มา

ปัญหาที่เกิดขึ้นจริงที่คุณพยายามแก้ไขคืออะไร? ไฟล์บันทึกใหญ่เกินไป? ถามตั้งแต่ฉันไม่เห็นปัญหากับการมีข้อมูลนี้ในบันทึกซึ่งโดยปกติแล้วมนุษย์จะไม่ได้อ่านและมีขนาดเพิ่มขึ้นเล็กน้อย

— Hennes

@Hennes - ปัญหาคือว่าsyslogและdmesgถูกน้ำท่วมด้วยบันทึกการดีบักที่ไร้ประโยชน์และทำให้การเตือนและข้อผิดพลาดที่แท้จริงมองข้ามได้ง่ายขึ้น นอกจากนี้dmesgและsyslogควรอ่านโดยมนุษย์ (เช่นผู้ดูแลระบบ) นั่นคือจุดประสงค์ทั้งหมดของพวกเขา

— Martin Vegter

ความกังวลเกี่ยวกับน้ำท่วมข้อมูลสำคัญเป็นจุดดี

— Hennes

1

คุณอาจสนใจคำถามนี้ในเว็บไซต์ Superuser Stack-Exchange: จะหยุดข้อความเคอร์เนลไม่ให้เกิดน้ำท่วมคอนโซลได้อย่างไร

— perror

5

สำหรับ syslog คุณสามารถเพิ่มบรรทัดต่อไปนี้ใน/etc/syslog.conf:

kern.info; kern.debug   /dev/null

มันจะทิ้งข้อความเคอร์เนล. info และ. debug (ซึ่งถูกทิ้งด้วย loglevel = 5)

นอกจากนี้ยังdmesgสามารถใช้กับตัวเลือก-nในการแสดงข้อความที่มี loglevel บางอย่าง

— Marqin
แหล่งที่มา

4

บันทึกบางส่วนถูกพิมพ์โดยprintk ()ซึ่งคุณไม่สามารถปิดได้ และบางส่วนถูกพิมพ์โดยpr_debug ()ซึ่งอาจถูกปิดใช้งานขึ้นอยู่กับการกำหนดค่าของเคอร์เนล พฤติกรรมของpr_debug ()ถูกควบคุมโดยคุณสมบัติการดีบักแบบไดนามิก หากCONFIG_DYNAMIC_DEBUGตั้งแล้วทั้งหมดpr_debug ()โทรแบบไดนามิกสามารถเปิด / ปิดต่อ callsite โดยมีรายละเอียดของการแก้ปัญหาแบบไดนามิกที่นี่ หาก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

ดังนั้นตรวจสอบการกำหนดค่าเคอร์เนลของคุณและค้นหาว่าบันทึกเหล่านี้มาจากไหน จากนั้นคุณจะรู้วิธีปิดการใช้งาน

— Chris Tsui
แหล่งที่มา

อย่าลืมecho 8 > /proc/sys/kernel/printk: stackoverflow.com/questions/28936199/…

— Ciro Santilli 法轮功病毒审查审查六四事件法轮功

0

นอกเหนือจากการตั้งค่าloglevelจาก KCL คุณยังสามารถปรับแต่ง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
}

ถ้าอย่างนั้นคุณจะเริ่มต้นใหม่ด้วยการบั๊กข้อมูลที่ จำกัด ในการบันทึกลงในบันทึก

— โคน
แหล่งที่มา

ฉันขอโทษ แต่แนะนำให้logrotateพลาดจุดโดยสิ้นเชิง ปัญหาของฉันไม่ใช่ว่า logfiles ของฉันใหญ่เกินไปและพื้นที่ดิสก์ของฉันหมด แต่ปัญหาคือข้อมูลการดีบักใน logfiles เหล่านั้นทำให้ข้อมูลที่เป็นประโยชน์เข้าถึงได้น้อยลง

— Martin Vegter

ขวา. ใช้ logrotate เพื่อย้ายบันทึกที่มีอึทั้งหมดออกไปเพื่อให้คุณมีไฟล์บันทึกที่ว่างเปล่าหลังจากบูตเพื่อให้คุณสามารถเห็นสิ่งที่สำคัญ การใช้ logrotate ของฉันที่นี่ไม่ใช่บัญญัติ: ใช้ mv ถ้าคุณต้องการ ประเด็นก็คือเพื่อให้อึออกจากทางทันทีหลังจากบูตได้มากที่สุด

— อธิการ

หากคุณไม่ได้หมายความว่าข้อความเหล่านี้ทำให้เกิดปัญหาเวลาบูตหรือไม่ ในกรณีนี้โซลูชันที่ยอมรับนั้นเหมาะสมที่สุด

— อธิการ