ใครกำลังเติมดิสก์ของฉัน

ฉันมีดิสก์หลักของฉันเต็มแล้ว:

root@kodi:/# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.9G     0  1.9G   0% /dev
tmpfs           385M   12M  374M   3% /run
/dev/sda1        88G   84G     0 100% /
tmpfs           1.9G  4.0K  1.9G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
/dev/sdb1       917G  429G  442G  50% /media/Cloud
/dev/sdd1       917G  813G   58G  94% /media/Tera
cgmfs           100K     0  100K   0% /run/cgmanager/fs
tmpfs           385M     0  385M   0% /run/user/1000
root@kodi:/#

/ dev / sda1 เป็นดิสก์หลักของฉันที่ติดตั้ง ubuntu:

root@kodi:/home/fmf# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=9fab4895-7ccb-4415-b26d-311a17036cda       /               ext4    errors=remount-ro 0       1

# swap was on /dev/sda5 during installation
UUID=7b158f58-e4c1-4717-aa5f-dbeaa79ab93c       none            swap    sw              0       0

UUID=f9079f52-7661-48ad-9bc4-0d2452be66af       /media/Tera     ext2    defaults,nofail 0       0
UUID=fb1f92ee-54f5-44f8-ba92-544e90e6dfeb       /media/Cloud    ext2    defaults,nofail 0       0

root@kodi:/home/fmf#

ลองใช้ google search และพบคำสั่งบางอย่างเพื่อทดสอบว่าใครเป็นผู้รับผิดชอบ แต่ฉันไม่สามารถระบุได้ว่าใครเป็นผู้กรอก:

root@kodi:/# du --exclude=/media -cksh * | sort -hr | head -n 15
du: cannot access 'proc/16360/task/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/task/16360/fdinfo/3': No such file or directory
du: cannot access 'proc/16360/fd/3': No such file or directory
du: cannot access 'proc/16360/fdinfo/3': No such file or directory
1.3T    total
1.3T    media
3.5G    home
3.0G    usr
1010M   var
645M    root
630M    lib
99M     boot
17M     bin
15M     sbin
13M     etc
12M     run
196K    tmp
16K     lost+found
12K     srv
root@kodi:/#

เห็นได้ชัดว่าไม่มีไฟล์หรือไดเรกทอรีใดที่ใหญ่พอที่จะเติมเต็ม 84G ของดิสก์ของฉัน

บางวันที่ผ่านมาฉันพบว่าดิสก์เต็มเนื่องจากข้อผิดพลาด. xsession ที่บ้าไปแล้ว ฉันพบว่านี่เป็นข้อผิดพลาดที่รู้จักในอูบุนตูและฉันแก้ไขการสร้าง crontab line ซึ่งทุกสิบนาทีจะลบ. xsession-errors อันที่จริงตอนนี้ฉันไม่ได้มีมันในไดเรกทอรีบ้าน

มีอะไรให้ช่วยไหม?

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

@rinzwind มีจุดมุ่งหมายเพื่อพฤติกรรมนี้อย่างแน่นอนเมื่อเขา (ถูกต้อง) แนะนำให้ลบ cronjob และค้นหาข้อผิดพลาด นี่เป็นวิธีเดียวที่จะแก้ไขปัญหานี้ได้อย่างถูกต้อง

คุณสามารถตัด.xsession_errorsไฟล์ด้วย cronjob ดังนี้:

17 */2 * * *  truncate -cs 0 path/to/.xsession_errors

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

ใครกำลังเติมดิสก์ของฉัน

ตั้งแต่คุณทำเช่นนี้ ...

ฉันพบว่านี่เป็นข้อผิดพลาดที่รู้จักกันในอูบุนตูและฉันแก้ไขการสร้าง crontab ที่ทุกสิบนาทีลบ. xsession-errors

เป็นไปไม่ได้ที่จะตอบคำถามนี้

โปรดทำตามสิ่งต่อไปนี้เพื่อให้เราได้รับข้อผิดพลาดที่เราต้องดู:

• ลบบรรทัด crontab .xsessions_errorsที่คุณเพิ่มเอาว่า
• Reboot แล้วตรวจสอบจากบรรทัดคำสั่งสิ่งที่เติมขึ้นมาใช้.xsessions_errorstail -f 100 ~/.xsessions_errors
• เมื่อคุณพบปัญหาใด ๆ ที่เกิดขึ้นซ้ำ ๆ จำนวนมากให้คัดลอกบางส่วนลงในคำถาม
• เพิ่ม crontab line กลับเพื่อให้คุณสามารถใช้ระบบของคุณ
• รอการแก้ไขปัญหาและนำไปใช้แล้ว จากนั้นลบบรรทัด crontab อีกครั้ง (การลบ.xsessions_errorsไฟล์ควรหลีกเลี่ยงเสมอ)

เมื่อมีความแตกต่างใหญ่ (พูดมากกว่าสองสามเปอร์เซ็นต์) ระหว่าง (ในฐานะรูท) df -g /some/partition_rootและdu -gx /some/partition_root( -xบอกให้คุณ จำกัด ตัวเองในพาร์ติชันเดียวกันให้ใช้เพื่อตรวจสอบตัวอย่าง '/': อาจยังคงมีไฟล์อยู่ เปิดที่บางกระบวนการยังคงเขียน แต่คุณลบบนดิสก์ (ดังนั้น: ไฟล์ยังคงอยู่ตราบใดที่เปิดโดยกระบวนการและเติมพื้นที่ว่างในดิสก์ (df -g เห็นว่า) แต่เนื่องจากไม่มี ลิงก์ที่ยาวขึ้น (หรือชื่อไฟล์) ไปยัง inodes, du -gx คิดถึงมัน

ในกรณีของคุณเปรียบเทียบผลลัพธ์ของ:

df -g /
du -gx /

หากต้องการค้นหาว่าเป็นไฟล์ใดที่มีลิงก์น้อยกว่า 1 ลิงก์ (เช่นไฟล์ที่ถูกลบ แต่ยังเปิดอยู่):

lsof -nP +L1  /

ตรวจสอบชื่อกระบวนการและ pids เพื่อดูว่ากระบวนการใดที่เขียนไปยังไฟล์ "โกสต์" เหล่านั้นและดำเนินการตามนั้น (บางอย่างที่คุณสามารถหยุด / เริ่มและเมื่อพวกเขาหยุดไฟล์จะถูกปล่อยและพื้นที่ว่างเป็นอิสระ คนอื่นอาจจำเป็นต้องรีบูตที่เหมาะสม)