ไฟล์บันทึกขนาดใหญ่มากฉันต้องทำอย่างไร

( คำถามนี้เกี่ยวข้องกับปัญหาที่คล้ายกัน แต่พูดถึงไฟล์บันทึกที่หมุนได้)

วันนี้ฉันได้รับข้อความของระบบเกี่ยวกับ/varพื้นที่ที่ต่ำมาก

ตามปกติฉันดำเนินการคำสั่งในบรรทัดsudo apt-get cleanที่ปรับปรุงสถานการณ์เพียงเล็กน้อยเท่านั้น จากนั้นฉันก็ลบไฟล์บันทึกที่หมุนแล้วซึ่งให้การปรับปรุงน้อยมากอีกครั้ง

จากการตรวจสอบฉันพบว่าไฟล์บันทึกในบางไฟล์/var/logโตขึ้นอย่างมาก จะเฉพาะเจาะจงls -lSh /var/logให้

total 28G
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 kern.log
-rw-r----- 1 syslog            adm      14G Aug 23 21:56 syslog
-rw-rw-r-- 1 root              utmp    390K Aug 23 21:47 wtmp
-rw-r--r-- 1 root              root    287K Aug 23 21:42 dpkg.log
-rw-rw-r-- 1 root              utmp    287K Aug 23 20:43 lastlog

อย่างที่เราเห็นสองคนแรกนั้นเป็นคนที่ทำผิดกฎหมาย ฉันประหลาดใจเล็กน้อยว่าทำไมไฟล์ขนาดใหญ่ถึงไม่หมุน

ดังนั้นฉันควรทำอย่างไร เพียงแค่ลบไฟล์เหล่านี้แล้วรีบูต? หรือทำตามขั้นตอนที่รอบคอบกว่านี้

ฉันใช้ Ubuntu 14.04

อัพเดท 1

ในการเริ่มต้นระบบจะมีอายุเพียงไม่กี่เดือน ฉันต้องติดตั้งระบบตั้งแต่เริ่มต้นสองสามเดือนกลับมาหลังจากความผิดพลาดของฮาร์ดดิสก์

ตอนนี้ตามคำแนะนำในคำตอบนี้ฉันจะตรวจสอบไฟล์บันทึกที่ละเมิดโดยใช้tailก่อนไม่แปลกใจเลย แล้วสำหรับการตรวจสอบลึกผมดำเนินการสคริปต์นี้จากคำตอบเดียวกัน

for log in /var/log/{syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

กระบวนการนี้ใช้เวลาหลายชั่วโมง ผลลัพธ์อยู่ในแนวของ

/var/log/syslog :
71209229  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
53929977  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
17280298  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 54763121030042024)
       <snipped>

/var/log/kern.log.1 :
71210257  Rafid-Hamiz-Dell kernel:  attempt to access beyond end of device
71209212  Rafid-Hamiz-Dell kernel:  sda3: rw=1, want=7638104968240336200, limit=1681522688
   1639  Rafid-Hamiz-Dell kernel:  EXT4-fs warning (device sda3): ext4_end_bio:317: I/O error -5 writing to inode 6819258 (offset 0 size 4096 starting block 954763121030042024)

( /dev/sda3คือโฮมไดเร็กตอรี่ของฉันในขณะที่เราหาได้

lsblk /dev/sda
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 931.5G  0 disk 
├─sda1   8:1    0 122.1G  0 part /
├─sda2   8:2    0   7.6G  0 part [SWAP]
└─sda3   8:3    0 801.8G  0 part /home

เหตุใดกระบวนการจึงต้องการเขียนเกินขีด จำกัด จึงอยู่นอกขอบเขตของความเข้าใจของฉัน บางทีฉันอาจต้องการถามคำถามอื่นในฟอรัมนี้หากดำเนินการต่อไปแม้ว่าจะมีการอัปเดตระบบ)

จากคำตอบนี้ (คุณอาจต้องการตรวจสอบสิ่งนี้เพื่อความเข้าใจที่ลึกซึ้งยิ่งขึ้น) ฉันดำเนินการแล้ว

sudo su -
> kern.log
> syslog

ตอนนี้ไฟล์เหล่านี้มีขนาดเป็นศูนย์ ระบบทำงานได้ดีก่อนและหลังการรีบูต

ฉันจะดูไฟล์เหล่านี้ (รวมถึงไฟล์อื่น ๆ ) ในอีกไม่กี่วันข้างหน้าและรายงานกลับมาหาก
พวกเขาประพฤติตัวไม่เหมาะสม

ในฐานะที่เป็นโน้ตสุดท้ายทั้งไฟล์ที่ละเมิด ( kern.logและsyslog) ถูกตั้งค่าให้หมุนตามการตรวจสอบไฟล์ ( grepช่วย) ภายใน /etc/logrotate.d/แสดง

อัพเดท 2

ล็อกไฟล์หมุนได้จริง ดูเหมือนว่าจะบรรลุถึงขนาดใหญ่ในวันเดียว

เพียงแค่ลบไฟล์เหล่านี้แล้วรีบูต?

ไม่ล้างข้อมูล แต่ไม่ได้ใช้rmเพราะอาจทำให้ระบบขัดข้องขณะที่คุณพิมพ์touchคำสั่งเพื่อสร้างใหม่

วิธีที่สั้นที่สุด:

cd /var/log
sudo su
> lastlog
> wtmp
> dpkg.log 
> kern.log
> syslog
exit

sudoถ้าไม่ได้ขุดรากถอนโคนจะต้อง นำมาจากคำตอบอื่นใน AU

ก่อนที่คุณจะทำเช่นนั้น ทำtail {logfile}และตรวจสอบว่ามีเหตุผลสำหรับพวกเขาที่จะใหญ่ หากระบบนี้มีอายุหลายปีไม่น่าจะมีเหตุผลและการแก้ไขปัญหานั้นดีกว่าปล่อยให้เรื่องนี้ดำเนินต่อไป

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

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

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

อาจเป็นการพยายามสร้างสิ่งที่กรอกบันทึก - โดยเพียงแค่ตรวจสอบโดยใช้สายตาlessหรือtailคำสั่ง

tail -n 100 /var/log/syslog

หรือถ้าเส้นที่มีการละเมิดนั้นฝังลึกเกินไปที่จะเห็นสิ่งที่เกิดขึ้นได้อย่างง่ายดาย

for log in /var/log/{dmesg,syslog,kern.log}; do 
  echo "${log} :"
  sed -e 's/\[[^]]\+\]//' -e 's/.*[0-9]\{2\}:[0-9]\{2\}:[0-9]\{2\}//' ${log} \
  | sort | uniq -c | sort -hr | head -10
done

(หมายเหตุ: อาจใช้เวลาสักครู่เนื่องจากไฟล์ขนาดใหญ่ดังกล่าว) ซึ่งจะพยายามตัดการประทับเวลาจากนั้นนับข้อความที่เกิดขึ้นบ่อยที่สุด

วิธีของฉันสำหรับล็อกไฟล์ระบบที่สะอาดคือสิ่งนี้ ขั้นตอนที่ 1 และ 2 เป็นทางเลือก แต่บางครั้งคุณจำเป็นต้องตรวจสอบบันทึกเก่า ๆ และการสำรองข้อมูลบางครั้งก็มีประโยชน์ ;-)

1. ทางเลือก: คัดลอกไฟล์บันทึก

   cp -av --backup=numbered file.log file.log.old
   

2. ทางเลือก: ใช้ Gzip ในสำเนาของบันทึก

   gzip file.log.old
   

3. ใช้ / dev / null สำหรับไฟล์ที่สะอาด

   cat /dev/null > file.log
   

และเราใช้สำหรับบันทึกนี้ (เฉพาะเซิร์ฟเวอร์หลาย ๆ แห่ง) ล็อกและดำเนินการรายสัปดาห์โดยสคริปต์ cron ซึ่งไฟล์ทั้งหมดที่มี * .1 (หรือหมุนครั้งถัดไป) บีบอัดโดย gzip

ฉันติดตั้ง Ubuntu 16.04 วันนี้และฉันสังเกตเห็นปัญหาเดียวกัน อย่างไรก็ตามฉันแก้ไขด้วย busybox-syslogd ได้! ฉันเพิ่งติดตั้งแพ็คเกจและปัญหาได้รับการแก้ไขแล้ว :)

$ sudo apt-get install busybox-syslogd

หลังจากติดตั้งแพ็คเกจแล้วให้รีเซ็ตsyslogและkern.log:

sudo tee /var/log/syslog /var/log/kern.log </dev/null

ฉันหวังว่าโซลูชันง่ายๆนี้มีประโยชน์สำหรับคนอื่น ๆ