Хто заповнює мій диск?

У мене основний диск повністю заповнений:

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 і знайшов команди, щоб перевірити, хто відповідальний, але я не можу зрозуміти, хто його заповнює:

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-помилки, які зійшли з розуму. Я виявив, що це відома помилка в ubuntu, і я вирішив створити лінію crontab, яка кожні десять хвилин видаляє .xsession-помилки. Насправді зараз у мене цього немає в домашньому довіднику.

Будь-яку допомогу, будь ласка?

Проблема вашої cronjob полягає в тому, що .xsession_errorsвона, швидше за все, відкривається деякими програмами або системними службами, тому вона буде прихована від таблиці файлової системи при видаленні, але вона все ще знаходиться на диску, і все одно в неї будуть записані помилки.
Так він заповнить диск, але тепер його вже не можна побачити.

@rinzwind має на меті саме таку поведінку, коли він (правильно) пропонує зняти роботу і шукати помилки. Це єдиний спосіб виправити цю проблему належним чином.

Як вирішення, ви можете усікати .xsession_errorsфайл таким чином:

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

Але перш ніж це зробити, РЕАЛЬНО слід спробувати виправити основні проблеми, які створюють ці повідомлення про помилки .xsession_errors

Хто заповнює мій диск?

оскільки ти це робиш ...

Я виявив, що це відома помилка в ubuntu, і я вирішив створити лінію crontab, яка кожні десять хвилин видаляє .xsession-помилки

відповісти на це питання неможливо.

Будь ласка, виконайте наступне, щоб отримати нам помилки, які нам потрібно побачити:

• Видаліть ту лінію, яку ви додали, що видаляє .xsessions_errors.
• Перезавантаження , а потім перевірити з командного рядка , що заповнюється з .xsessions_errorsвикористанням tail -f 100 ~/.xsessions_errors.
• Коли ви знайдете якісь проблеми, які повторюються, скопіюйте деякі з них у своє запитання.
• Додайте рядок crontab назад, щоб ви могли використовувати вашу систему.
• Зачекайте виправлення проблеми та застосуйте потім. Потім знову видаліть рядок crontab ( .xsessions_errorsзавжди слід уникати видалення файлу).

Коли є великі відмінності (скажімо, більше ніж на кілька відсотків) між (як root) df -g /some/partition_rootі du -gx /some/partition_root( -xговорить du, щоб обмежитися тим самим розділом, корисно перевірити '/', наприклад): ймовірно, файли все ще відкрив, що деякі процеси все ще пишуть, але ви видалили на диску (отже: файл все ще існує, доки він відкритий процесами, і заповнює дисковий простір (df -g бачить це), але як немає довші посилання (або назви файлів) до його індексів, du -gx їх не вистачає.

У вашому випадку порівняйте результати:

df -g /
du -gx /

Щоб дізнатися, які файли мають менше 1 посилання (тобто видалені файли, але все ще відкриті):

lsof -nP +L1  /

Перевірте назви процесів та підручники, щоб побачити, які саме процеси записують у ці "привидні" файли, і дійте відповідно (деякі з них ви зможете зупинити / запустити, а коли вони зупиняються, файл буде випущений та звільнений його простір, інші можуть потребувати належної перезавантаження)