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

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

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 стремится именно к этому поведению, когда он (правильно) предлагает удалить cronjob и искать ошибки. Это единственный способ правильно исправить эту проблему.

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

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

Но прежде чем делать это, вы должны попытаться исправить основные проблемы, которые создают эти сообщения об ошибках в .xsession_errors

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

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

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

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

Следуйте приведенным ниже, чтобы получить ошибки, которые нам нужны:

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

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

В вашем случае сравните выходы:

 df -g / du -gx / 

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

 lsof -nP +L1 / 

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