![谁在填满我的磁盘?](https://linux22.com/image/1058957/%E8%B0%81%E5%9C%A8%E5%A1%AB%E6%BB%A1%E6%88%91%E7%9A%84%E7%A3%81%E7%9B%98%EF%BC%9F.png)
我的主磁盘已经完全填满:
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#
进行了一些谷歌搜索,并找到了一些命令来测试谁是负责人,但我不知道谁在填写它:
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-errors 疯狂地出现。我发现这是 ubuntu 中的一个已知错误,我通过创建 crontab 行解决了这个问题,该行每十分钟删除一次 .xsession-errors。事实上,现在我的主目录中不再有它了。
请问有什么帮助吗?
答案1
您的 cronjob 的问题在于它.xsession_errors
很可能仍由某些应用程序或系统服务打开,这就是为什么它在删除时会从文件系统表中隐藏,但它仍在磁盘上,并且仍然会将错误写入其中。
因此它会填满磁盘,但现在您再也看不到它了。
@rinzwind 的目标正是这种行为,他(正确地)建议删除 cronjob 并查找错误。这是正确修复此问题的唯一方法。
作为一种解决方法,你可以.xsession_errors
使用这样的 cronjob 截断文件:
17 */2 * * * truncate -cs 0 path/to/.xsession_errors
但在执行此操作之前,你真的应该尝试修复导致这些错误消息的根本问题.xsession_errors
答案2
谁在填满我的磁盘?
因为你这样做了……
我发现这是 ubuntu 中的一个已知错误,我解决了这个问题,创建了一条 crontab 行,每十分钟删除一次 .xsession-errors
这个问题无法回答。
请按照以下步骤获取我们需要看到的错误:
- 删除您添加的删除 crontab 行
.xsessions_errors
。 .xsessions_errors
重新启动,然后从命令行检查使用的内容tail -f 100 ~/.xsessions_errors
。- 当您发现任何重复出现的问题时,请将其中一些问题复制到您的问题中。
- 添加 crontab 行以便您可以使用您的系统。
- 等待问题修复并应用。然后再次删除 crontab 行(
.xsessions_errors
应始终避免删除该文件)。
答案3
当 (以 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 /
检查进程名称和 pid 以查看哪些进程正在写入这些“幽灵”文件,并采取相应的措施(您可能能够停止/启动某些进程,当它们停止时,文件将被释放并且其空间将被释放,其他进程可能需要适当的重新启动)