Кто заполняет мой диск?

Мой основной диск полностью заполнен:

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-errors. На самом деле сейчас у меня его больше нет в моем домашнем каталоге.

Любая помощь, пожалуйста?

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

@rinzwind стремится именно к такому поведению, когда он (правильно) предлагает удалить cronjob и искать ошибки. Это единственный способ правильно решить эту проблему.

В качестве обходного пути вы можете обрезать .xsession_errorsфайл с помощью cronjob:

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

Но прежде чем сделать это, вы ДЕЙСТВИТЕЛЬНО должны попытаться исправить основные проблемы, которые создают эти сообщения об ошибках в .xsession_errors

Кто заполняет мой диск?

так как вы делаете это ...

Я обнаружил, что это известная ошибка в Ubuntu, и я решил создать строку crontab, которая каждые десять минут удаляет .xsession-errors

невозможно ответить на этот вопрос.

Пожалуйста, следуйте приведенным ниже инструкциям, чтобы получить информацию об ошибках, которые нам нужны

• Удалите ту добавленную вами строку crontab, которая удаляет .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 видит это), но так как нет более длинные ссылки (или имена файлов) на свои inode, du -gx пропускает их.

В вашем случае сравните результаты:

df -g /
du -gx /

Чтобы узнать, какие файлы содержат менее 1 ссылки (то есть, удаленные файлы, но все еще открытые):

lsof -nP +L1  /

Проверьте имена процессов и pids, чтобы увидеть, какие процессы записывают в эти «призрачные» файлы, и действуйте соответствующим образом (некоторые из них вы сможете остановить / запустить, и когда они будут остановлены, файл будет освобожден, а его пространство освободится, другие могут потребовать правильной перезагрузки)