CentOS 7.9 根目录满了，找不到占用空间的文件，也没有deleted进程 -另一种思路解决方法-
说明：这几天发现生产环境中的一台应用服务器根目录爆满，但前期一直没有找到问题所在。终于今天找到的问题并得以解决，在此分享下解决思路和方案，并同时做一个记录。
操作系统：CenOS 7.9 根目录文件占用正常，已重启过服务器，也释放过deleted进程，空间依然占用。
1>通过宝塔巡检发现根目录空间异常
2>使用“df -h"发现磁盘使用率已达到96%
[root@**_app ~]# df -h Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 27M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/mapper/centos-root 50G 48G 2.2G 96% / //*发现根目录的容量已经使用了96% 只剩余2.2G的空间可供使用 /dev/sda1 1014M 237M 778M 24% /boot /dev/mapper/centos-home 827G 44G 783G 6% /home tmpfs 3.2G 0 3.2G 0% /run/user/0 //192.168.22.10/backup 1.0T 297G 728G 29% /windows [root@**_app ~]#
3>使用"df -i"查询inode占用情况，发现占用率在3% 是正常的。
[root@**_app ~]# df -i Filesystem Inodes IUsed IFree IUse% Mounted on devtmpfs 4082131 509 4081622 1% /dev tmpfs 4085081 2 4085079 1% /dev/shm tmpfs 4085081 938 4084143 1% /run tmpfs 4085081 16 4085065 1% /sys/fs/cgroup /dev/mapper/centos-root 4687952 130756 4557196 3% / //*看到根目录的inode占用率在3% 属于正常情况 /dev/sda1 524288 341 523947 1% /boot /dev/mapper/centos-home 433352704 155813 433196891 1% /home tmpfs 4085081 1 4085080 1% /run/user/0 //192.168.22.10/backup 0 0 0 - /windows [root@**_app ~]#
4>查询根目录空间使用情况
进入根目录：cd /
查看根目录实际占用文件大小： du -h -x --max-depth=1
根目录空间有50G，实际占用文件只有10G不到，另外占用的将近40GB的文件找不到。
[root@**_app ~]# cd / [root@**_app /]# du -h -x --max-depth=1 36M ./etc 720K ./root 456M ./var 212K ./tmp 1.7G ./usr 0 ./media 0 ./mnt 0 ./opt 0 ./srv 5.0G ./www 4.0K ./patch 7.2G . //*看到根目录文件总用量在7.2G，没有达到50G [root@**_app /]#
5>初期思路(删除文件后占用空间未释放导致)：
网上有教程说是已删除的文件占用导致的空间未释放。
通过：lsof / | grep deleted 指令，查看当前系统句柄对已删除文件未释放情况。
发现占用的文件大小是是空的(都是0)。所以可以排除文件占用的问题。
[root@**_app /]# lsof / |grep deleted php-fpm 9686 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9689 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9692 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9694 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9695 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9696 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9697 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9698 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9699 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9700 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9701 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9702 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9703 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9704 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9705 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9706 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9707 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 9708 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) mysqld 10517 mysql 5u REG 253,0 0 67772106 /tmp/ibXplGAM (deleted) mysqld 10517 mysql 6u REG 253,0 0 67772642 /tmp/ibjllXSI (deleted) mysqld 10517 mysql 7u REG 253,0 0 68364239 /tmp/ibdxKebF (deleted) mysqld 10517 mysql 8u REG 253,0 0 68369312 /tmp/ib2aON9x (deleted) mysqld 10517 mysql 14u REG 253,0 0 68933157 /tmp/ibrdaFUu (deleted) php-fpm 10609 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) php-fpm 10662 www 3u REG 253,0 0 67160174 /tmp/ZCUD4i69BL (deleted) [root@**_app /]#
如果是因为删除了文件，且文件被程序占用导致资源未回收的这种问题的话，那么到这一步只要使用kill -hup pid号，进行杀死后会自动重启，资源也得以释放，问题便可以解决问题了。
但很显然，我这边碰到的并不是这个原因，所以还要寻找其它的解决方法，继续排查：
6>Windows mount排查思路1：
最后考虑到之前有动过另一台Windows服务器的共享，该服务器的共享mouna(挂载)到Linux服务器的windows目录中。遂开始排查该目录情况。(SSH输出内容中过滤了部分重复、隐私信息)
[root@**_app /]# cd /windows //*进入mount的windows目录 [root@**_app windows]# ls //*查看目录情况 database site //*发现有两个目录 [root@**_app windows]# cd database //*先查看database目录 [root@**_app database]# du -sh * //*查看database目录文件占用情况 41M db_**_dev_20211209_220002.sql.gz 41M db_**_dev_20211209_230002.sql.gz 41M db_**_dev_20211210_000001.sql.gz 41M db_**_dev_20211210_010001.sql.gz //*该目录文件很多、后面不贴出来了，基本都在41M左右，与windwos服务器中查看的情况一致。 [root@**_app database]# [root@**_app database]# cd .. //*返回上级目录 [root@**_app windows]# cd site //*查看site目录 [root@**_app site]# du -sh * //*查看site目录文件占用情况 41G web_saas.***.com.cn_20211211_010001.tar.gz 41G web_saas.***.com.cn_20211212_010001.tar.gz 41G web_saas.***.com.cn_20211213_010001.tar.gz 41G web_saas.***.com.cn_20211215_010002.tar.gz 41G web_saas.***.com.cn_20211216_010001.tar.gz 41G web_saas.***.com.cn_20211217_010001.tar.gz [root@**_app site]# //*看到site目录和windows服务器下共享中的文件内容是一致的，所以刚开始的时候便排除了该目录的问题
刚开始的时候排查过mount的目录，因为其内容与Windows 服务器共享出来的内容一致，便很快排除了mount目录的问题。
但后期一整套排查下来，近期只有动过这台服务器的共享，所以还是决定从mount上着手排查。
7>mount 排查 "umount":
先把挂载的windows目录使用"umount"命令卸载看看结果：
[root@**_app site]# cd / //*进入根目录 [root@**_app /]# umount windows //*对windows进行unmout [root@**_app /]# cd /windows //*进入根目录下windows目录 [root@**_app windows]# ls //*查看发现存在一个site目录，正常情况下umount后应该是空的才对，感觉问题已经定位到了。继续往下看 site [root@**_app windows]# cd site //*进入site目录 [root@**_app site]# du -sh * //*查看site目录文件占用情况 4.0K web_posapi.***.com.cn_20211214_010001.tar.gz 24M web_pos.***.com.cn_20211214_010001.tar.gz 41G web_saas.***.com.cn_20211214_010001.tar.gz //*最大的文件 4.0K web_www.***.com.cn_20211214_010001.tar.gz [root@**_app site]# //*多出来的40个G的空间终于定位到了....
至此，问题已经大致定位出来了，由于之前变动过windwos mount，导致当日网络备份失败，宝塔自动备份到根目录的windows 目录下了....
8>删除占用文件：
进入到"/windows/site"目录下，执行"rm -rf *"删除当前目录下所有文件。
注意：注意执行该命令前需要区分当前目录，否则会删错，导致文件丢失
[root@**_app site]# rm -rf * //*删除当前目录下所有文件，注意执行该命令前需要区分当前目录，否则会删错，导致文件丢失 [root@**_app site]# ls //*再次查看，文件已删除 [root@**_app site]#
9>重新mount并核对：
[root@**_app site]# mount -a //*重新mount，因为我的mount配置是写到fstab里面的，可以直接这样操作 [root@**_app site]# df -h //*再次查看磁盘空间 Filesystem Size Used Avail Use% Mounted on devtmpfs 16G 0 16G 0% /dev tmpfs 16G 0 16G 0% /dev/shm tmpfs 16G 27M 16G 1% /run tmpfs 16G 0 16G 0% /sys/fs/cgroup /dev/mapper/centos-root 50G 7.3G 43G 15% / //*根目录空间已释放 /dev/sda1 1014M 237M 778M 24% /boot /dev/mapper/centos-home 827G 44G 783G 6% /home tmpfs 3.2G 0 3.2G 0% /run/user/0 //192.168.22.10/backup 1.0T 297G 728G 29% /windows //*mount也成功挂载 [root@**_app site]#
查看宝塔：
总结：
1.如果如果是因为删除了文件，且文件被程序占用导致资源未回收的这种问题的话，那么到第5步的时候就可以解决问题了，后期再使用kill -hup pid号，进行杀死后会自动重启，即可。
2.处理这类问题一定要结合近期的变动来处理，正常情况下只要程序没有大动过，都可以排除程序的问题，再着手排查近期改动所带来的影响。
