Кто заполняет мой диск?
Мне заполнили мой первичный диск полностью:
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 мой первичный диск, где человечность установлена:
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-ошибок, которые сошли с ума. Я нашел, что это - известная ошибка в человечности, и я решил создание crontab строки, которые каждые десять минут удаляют .xsession-ошибки. На самом деле прямо сейчас у меня больше нет его в моем корневом каталоге.
Какая-либо справка?
3 ответа
Когда есть большие различия (скажем, более чем на несколько процентов) между (как корень) df -g /some/partition_root и du -gx /some/partition_root (-x говорит du ограничиться одним и тем же разделом, полезно проверить «/» например): возможно, еще есть файл (ы), в которые все еще записываются некоторые процессы, но которые вы удалили на диск (следовательно: файл все еще существует, пока он открыт процессами, и заполняет место на диске) (df -g видит это), но поскольку больше нет ссылок (или имен файлов) на его inode, du -gx пропускает их.
В вашем случае сравните выходные данные:
df -g /
du -gx /
lsof -nP +L1 /
Проверьте имена процессов и pids, чтобы увидеть, какие процессы записывают в них " «призрачные» файлы и действуйте соответствующим образом (некоторые из них вы сможете остановить / запустить, и когда они будут остановлены, файл будет освобожден и его пространство освободится, другие могут потребовать надлежащей перезагрузки)
, Кто заполняет мой диск?
, так как Вы делаете это...
я нашел, что это - известная ошибка в человечности, и я решил создание crontab строки, которые каждые десять минут удаляют .xsession-ошибки
, невозможно ответить на этот вопрос.
следуйте за следующим для получения нас ошибки, которые мы должны видеть:
- Удаляют это crontab строка, Вы добавили, что это удаляет
.xsessions_errors. - Перезагрузка и затем проверяет из командной строки, что заполняется
.xsessions_errorsиспользованиеtail -f 100 ~/.xsessions_errors. - , Когда Вы находите любые проблемы, которые повторяются много копии некоторые из них в Ваш вопрос.
- Добавляют crontab строку назад, таким образом, можно использовать систему.
- Ожидают фиксации для проблемы и применяются затем. Затем удалите crontab строку снова (удаляющий
.xsessions_errors, файла нужно всегда избегать).
Проблема с Вашим cronjob - это .xsession_errors скорее всего, все еще открыт некоторыми приложениями или системными службами, который является, почему это будет скрыто от таблицы файловой системы при удалении, но это все еще находится на диске, и все еще ошибки будут записаны в него.
Таким образом, это заполнит диск, но теперь Вы больше не видите его.
@rinzwind стремится точно к этому поведению, когда он (правильно) предлагает удалить cronjob и искать ошибки. Это - единственный способ решить эту проблему правильно.
Как обходное решение Вы могли усечь .xsession_errors файл с cronjob как это:
17 */2 * * * truncate -cs 0 path/to/.xsession_errors
Но прежде, чем сделать это ДЕЙСТВИТЕЛЬНО необходимо попытаться решить базовые проблемы, которые создают те сообщения об ошибках в .xsession_errors