Ai đang lấp đầy đĩa của tôi?

Tôi có đĩa chính đầy đủ:

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 là đĩa chính của tôi, nơi cài đặt ubfox:

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#

Đã tìm kiếm trên google và tìm thấy một số lệnh để kiểm tra ai chịu trách nhiệm, nhưng tôi không thể tìm ra ai đang điền vào nó:

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:/#

Rõ ràng không có bất kỳ tập tin hoặc thư mục nào quá lớn để lấp đầy 84G của đĩa của tôi.

Vài ngày trước, tôi thấy rằng đĩa đã đầy do lỗi .xsession-phát điên. Tôi thấy đây là một lỗi đã biết trong ubfox và tôi đã giải quyết việc tạo một dòng crontab mà cứ sau mười phút lại xóa .xsession-lỗi. Thực tế bây giờ tôi không còn có nó trong thư mục nhà của tôi.

Bất kỳ giúp đỡ, xin vui lòng?

Vấn đề với cronjob của bạn .xsession_errorsrất có thể vẫn được mở bởi một số ứng dụng hoặc dịch vụ hệ thống, đó là lý do tại sao nó sẽ bị ẩn khỏi bảng hệ thống tệp khi bị xóa, nhưng nó vẫn còn trên đĩa và vẫn còn lỗi được ghi vào nó.
Vì vậy, nó sẽ lấp đầy đĩa, nhưng bây giờ bạn không thể nhìn thấy nó nữa.

@rinzwind nhắm đến chính xác hành vi này khi anh ta (chính xác) đề nghị loại bỏ cronjob và tìm kiếm các lỗi. Đây là cách duy nhất để khắc phục vấn đề này đúng cách.

Như một giải pháp thay thế, bạn có thể cắt bớt .xsession_errorstệp bằng một cronjob như thế này:

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

Nhưng trước khi làm điều này, bạn THỰC SỰ nên cố gắng khắc phục các sự cố tiềm ẩn tạo ra các thông báo lỗi đó trong .xsession_errors

Ai đang lấp đầy đĩa của tôi?

kể từ khi bạn làm điều này ...

Tôi thấy đây là một lỗi đã biết trong ubfox và tôi đã giải quyết việc tạo một dòng crontab mà cứ sau mười phút lại xóa .xsession-lỗi

không thể trả lời câu hỏi này

Vui lòng làm theo các cách sau để nhận cho chúng tôi các lỗi chúng tôi cần xem:

• Xóa dòng crontab mà bạn đã thêm mà loại bỏ .xsessions_errors.
• Khởi động lại và sau đó kiểm tra từ dòng lệnh những gì đang điền .xsessions_errorsbằng cách sử dụng tail -f 100 ~/.xsessions_errors.
• Khi bạn tìm thấy bất kỳ vấn đề nào được lặp đi lặp lại, hãy sao chép một số vấn đề vào câu hỏi của bạn.
• Thêm dòng crontab trở lại để bạn có thể sử dụng hệ thống của mình.
• Đợi một sửa chữa cho vấn đề và áp dụng sau đó. Sau đó xóa dòng crontab một lần nữa (xóa .xsessions_errorstập tin nên luôn luôn phải tránh).

Khi có sự khác biệt lớn (giả sử, hơn một vài phần trăm) giữa (với quyền root) df -g /some/partition_rootvà du -gx /some/partition_root( -xbảo du tự giới hạn trong cùng một phân vùng, chẳng hạn, hãy kiểm tra '/' chẳng hạn): có thể vẫn còn tệp (s) đã mở rằng một số tiến trình vẫn đang ghi, nhưng bạn đã xóa trên đĩa (do đó: tệp vẫn tồn tại miễn là nó được mở bởi các tiến trình và lấp đầy không gian đĩa (df -g thấy vậy) nhưng vì không có các liên kết dài hơn (hoặc tên tệp) đến các nút của nó, du -gx bỏ lỡ chúng.

Trong trường hợp của bạn, hãy so sánh kết quả đầu ra của:

df -g /
du -gx /

Để tìm ra các tệp có ít hơn 1 liên kết (nghĩa là các tệp đã bị xóa nhưng vẫn mở):

lsof -nP +L1  /

Kiểm tra tên quy trình và các giá trị để xem các quy trình ghi vào các tệp "ma" đó và hành động tương ứng (một số bạn có thể dừng / bắt đầu và khi chúng bị dừng, tệp sẽ được giải phóng và không gian của nó được giải phóng, những người khác có thể cần phải khởi động lại thích hợp)