阅读 808

Linux中出现“No space left on device”错误的排查与解决方法

篇文章主要给大家介绍了关于在Linux中出现"No space left on device"错误的排查与解决方法,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面来一起看看吧。

前言

最近这两天登陆服务器,发现用 wget 下载文件的时候提示“No space left on device”,而且连使用 tab 键进行补全时也会提示该错误。

之前遇到过一次这种问题,是由于磁盘空间被占满了,导致无法创建新文件。正常情况下,删除一些文件来释放空间,即可解决该问题。

当我使用 df 命令查看分区情况时,结果如下:

1
2
3
4
5
6
7
# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/vda1 29G 29G 0 100% /
udev  10M 0 10M 0% /dev
tmpfs  101M 232K 100M 1% /run
tmpfs  5.0M 0 5.0M 0% /run/lock
tmpfs  405M 0 405M 0% /run/shm

看到这里,我以为磁盘真的被 100% 占用了,于是就查看了各目录的占用情况:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# du -sh /*
8.8M /bin
30M /boot
0 /dev
5.3M /etc
24K /home
0 /initrd.img
205M /lib
4.0K /lib64
16K /lost+found
8.0K /media
4.0K /mnt
4.0K /opt
0 /proc
2.5G /root
232K /run
5.2M /sbin
8.0K /srv
0 /sys
4.0K /tmp
2.6G /usr
1.8G /var
0 /vmlinuz

很明显,总共的磁盘占用完全不到 10G,磁盘理论上并未被占满。

这种情况下,很可能是小文件过多,导致 inode 急剧增加,消耗完 inode 区域的空间。

如果真是如此,那么即使磁盘空间有剩余,但由于无法创建新的 inode 来存储文件的元信息,也就无法创建新文件。

因此,我用 df 命令进行验证:

1
2
3
4
5
6
7
# df -ih
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/vda1 1.9M 299K 1.6M 17% /
udev  123K 299 123K 1% /dev
tmpfs  126K 249 125K 1% /run
tmpfs  126K 4 126K 1% /run/lock
tmpfs  126K 2 126K 1% /run/shm

可以看到,inode 区域只被占用了一小部分,还有大量的空间未使用,所以也不是 inode 区域被占满的问题。

到了这里,我的内心是非常郁闷的。这个问题直接导致了Apache、MySql以及其它的一些服务均无法启动,服务器已经基本没法使用了,然而原因却扑朔迷离。

最后,服务器提供商告诉我另一种可能的情况,就是有些文件删除时还被其它进程占用,此时文件并未真正删除,只是标记为 deleted,只有进程结束后才会将文件真正从磁盘中清除。

于是我通过 lsop 命令查看了被进程占用中的文件:

1
2
3
4
5
6
7
8
# lsof | grep deleted
mysqld 1952 2982 mysql 5u REG  254,1  0 127 /tmp/ibzMEe4z (deleted)
mysqld 1952 2982 mysql 6u REG  254,1  0 146 /tmp/ibq6ZFge (deleted)
mysqld 1952 2982 mysql 10u REG  254,1  0 150 /tmp/ibyNHH8y (deleted)
apache2 2869  root 9u REG  254,1  0 168 /tmp/.ZendSem.2w14iv (deleted)
apache2 2869  root 10w REG  0,16  0 11077 /run/lock/apache2/rewrite-map.2869 (deleted)
...
python 3102  root 1w REG  254,1 22412342132 264070 /var/log/nohup.out (deleted)

终于找到了罪魁祸首,原来是在后台运行的 Python 脚本,源源不断地将输出保存到 /var/log/nohup.out 文件中,文件大小居然达到了20G+!

前阶段在后台运行脚本之后,就没再管过它。估计是我在 Python 运行过程中删掉了 nothup.out 文件,由于该文件被占用,所以只能先标记为 deleted,而未真正删除,最后导致磁盘爆满。

这次的教训提醒了我,不能将任务简单放到后台就放任不管,特别是使用 nohup 命令时,所有的输出都会被不断地添加到同一个文件中,如果该进程不会自己终止,就可能导致输出文件占满整个磁盘。

总结

以上就是这篇文章的全部内容了,希望本文的内容对大家的学习或者工作能带来一定的帮助



文章分类
后端
版权声明:本站是系统测试站点,无实际运营。本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容, 请发送邮件至 XXXXXXo@163.com 举报,一经查实,本站将立刻删除。
相关推荐