前言：今天上午接到一個網友的求助，說是服務器的根分區滿了。但是，找不到具體的大文件在哪里。由於故障確實很古怪，我就要來了故障服務器的相關賬戶密碼。
故障服務器相關環境：
系統：Centos 6.5
selinux： Disabled
iptables：開啟，但是默認策略全部是：ACCEPT
我方輔助服務器相關環境：
系統：Centos 6.5
selinux：Permissive
iptables：開啟，但是默認策略全部是：ACCEPT
首先我們在故障服務器上先簡單摸排一下問題的情況：
[root@abc ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/simfs 20G 970M 0 100% /
none 512M 4.0K 512M 1% /dev
none 512M 0 512M 0% /dev/shm
[root@abc ~]# df -ih
Filesystem Inodes IUsed IFree IUse% Mounted on
/dev/simfs 10M 27K 10M 1% /
none 128K 156 128K 1% /dev
none 128K 1 128K 1% /dev/shm
[root@abc ~]# cd /
[root@abc /]# du -sh *
6.7M bin
12K boot
4.0K dev
7.6M etc
4.0K home
11M lib
39M lib64
4.0K lost+found
4.0K media
4.0K mnt
16K nonexistent
4.0K opt
du: cannot access `proc/626/task/2558': No such file or directory
du: cannot access `proc/2551/task/2551/fd/4': No such file or directory
du: cannot access `proc/2551/task/2551/fdinfo/4': No such file or directory
du: cannot access `proc/2551/fd/4': No such file or directory
du: cannot access `proc/2551/fdinfo/4': No such file or directory
0 proc
478M root
13M sbin
4.0K selinux
4.0K srv
0 sys
152K tmp
960M usr
197M var
通過du命令，我們可以看到，磁盤空間並沒有使用多少。加起來不超過2G。
接下來我們看一下內存：
[root@abc ~]# free -m
total used free shared buffers cached
Mem: 1024 76 947 0 0 28
-/+ buffers/cache: 47 976
Swap: 0 0 0
內存也是充足的，並且沒有開啟swap分區。
接着查看一下磁盤掛載的情況：
[root@abc ~]# mount
/dev/simfs on / type simfs (rw,relatime)
proc on /proc type proc (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
none on /dev type devtmpfs (rw,relatime,mode=755)
none on /dev/pts type devpts (rw,relatime,gid=5,mode=620,ptmxmode=000)
none on /dev/shm type tmpfs (rw,relatime)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,relatime)
[root@abc ~]# fdisk /dev/simfs
Unable to open /dev/simfs
文件系統是:simfs，這個文件系統沒有見過，但是估計應該是vps供應商采用的，但是執行fdisk報錯，暫時記下
接下來top命令查看一下，看看是否有異常的進程：
通過top命令並沒有查到異常的進程，並且服務器的負載並不高。
接下來查看一下服務器打開的端口：
[root@abc tmp]# ss -tnlp
State Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN 0 0 *:22 *:* users:(("sshd",487,3))
LISTEN 0 0 :::1999 :::* users:(("python",740,4))
LISTEN 0 0 :::2000 :::* users:(("python",740,9))
LISTEN 0 0 :::2001 :::* users:(("python",740,11))
LISTEN 0 0 :::2002 :::* users:(("python",740,7))
LISTEN 0 0 :::2003 :::* users:(("python",740,6))
LISTEN 0 0 :::2004 :::* users:(("python",740,17))
LISTEN 0 0 :::2005 :::* users:(("python",740,19))
LISTEN 0 0 :::2006 :::* users:(("python",740,13))
LISTEN 0 0 :::22 :::* users:(("sshd",487,4))
LISTEN 0 0 :::2007 :::* users:(("python",740,15))
LISTEN 0 0 :::2008 :::* users:(("python",740,21))
LISTEN 0 0 :::2009 :::* users:(("python",740,23))
LISTEN 0 0 :::2010 :::* users:(("python",740,25))
可以看到服務器打開了很多端口，有sshd的22，另外一些都是python程序打開的。
因為這個是雲服務器，有可能是服務器端口放出來了，但是在雲廠商的web防火牆那邊把端口給封鎖掉了，所以我們通過輔助服務器再來掃描一下此服務器：
Starting Nmap 5.51 ( http://nmap.org ) at 2018-09-07 10:44 CST
Nmap scan report for abc.com (1.1.1.1)
Host is up (0.20s latency).
Not shown: 982 closed ports
PORT STATE SERVICE
22/tcp open ssh
135/tcp filtered msrpc
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
593/tcp filtered http-rpc-epmap
1999/tcp open tcp-id-port
2000/tcp open cisco-sccp
2001/tcp open dc
2002/tcp open globe
2003/tcp open finger
2004/tcp open mailbox
2005/tcp open deslogin
2006/tcp open invokator
2007/tcp open dectalk
2008/tcp open conf
2009/tcp open news
2010/tcp open search
4444/tcp filtered krb524
通過nmap掃描此服務器，發現確實是開了這么多端口，服務器的主人真的是膽子很大啊，大家千萬不要學習這位兄弟。
我們再通過ps查看一下跑的相關應用：
跑的進程非常的少，並且也沒有看起來很異常的進程。額，打碼的是因為此進程是：是是。大家忽略哈。
通過w命令，查看發現登錄此服務器的用戶有2個，一個是服務器主人，一個是我
此時，簡單的（額，算不算復雜？）服務器狀況排查，已經告一段落了。根據看到的情況，我懷疑是不是手動刪除了某個大文件，但是這個文件還被Python或者haproxy之類的進程占用中。導致磁盤沒有釋放出來。
我們通過lsof查看一下：
發現並沒有什么大的文件，sshd這個刪除看起來比較詭異。但是應該不是這個問題，因為詢問過服務器主人，發生這個問題后，他都已經重啟過服務器了，但是，此問題還是存在。
既然這樣，我懷疑是不是服務器被入侵了，命令都被換掉了。所以，我們看到的不一定是真相。
看一下df命令的大小，看看跟我輔助服務器的命令大小是否一致：
故障服務器：
[root@abc ~]# which df
/bin/df
[root@abc ~]# ll /bin/df
-rwxr-xr-x 1 root root 90544 Jun 25 2014 /bin/df
輔助服務器：
[root@CTE2-nginx-tomcat ~]# ll /bin/df
-rwxr-xr-x. 1 root root 95880 Nov 22 2013 /bin/df
服務器的系統版本是一致的，按道理來說,命令的大小應該是一致的。但是故障服務器的命令比輔助服務器的要小一些。
我們再看一下ps命令
故障服務器：
[root@abc tmp]# which ps
/bin/ps
[root@abc tmp]# ll /bin/ps
-rwxr-xr-x 1 root root 82024 Nov 15 2012 /bin/ps
輔助服務器：
[root@CTE2-nginx-tomcat tmp]# which ps
/bin/ps
[root@CTE2-nginx-tomcat tmp]# ll /bin/ps
-rwxr-xr-x. 1 root root 89480 Jul 12 2017 /bin/ps
這里的話，也是這個情況。故障服務器的命令比輔助服務器的大小要小一些
這就更能證明我們的推測：命令可能已經被動過手腳了，既然這樣，那我們把輔助服務器的正常命令上傳到故障服務器的/tmp目錄，然后再看看結果：
[root@CTE2-nginx-tomcat tmp]# scp /bin/ps 1.1.1.1:/tmp/
Address 1.1.1.1 maps to abc.com, but this does not map back to the address - POSSIBLE BREAK-IN ATTEMPT!
root@1.1.1.1's password:
ps 100% 87KB 87.4KB/s 00:00
好了，輔助服務器的ps命令已經傳到故障服務器，接下來我們看一下，是否會有相關的變化：
故障服務器：
輔助服務器的ps在故障服務器上執行結果：
額，這就很尷尬了。看起來並沒有什么問題，兩個命令的執行結果，是一致的。這台服務器並沒有什么異常的進程，並且負載也沒有升高。基本上可以排除被入侵的可能，一般情況下，有問題的命令是會比正常的命令大很多，而這里是稍微小一點點
比較遺憾，當時忘記查看命令的版本了，估計是版本有小差異導致的。
現在故障排查，陷入了迷茫，這種問題還真的是罕見。一定是哪里我們遺漏了相關的信息。忽然想起了那個奇怪的文件系統：simfs
既然沒有其他的問題，那有沒有可能是文件系統simfs導致的呢？
接下來我查詢了相關的資料：發現問題竟然是這樣的--You have no own file system. The /dev/simfs is just a fake device name that OpenVZ uses to create it's fake file system. Your real files (as well as the files of all other containers) reside on the host node's /vz filesystem. That filesystem (/vz on the hostnode) is full. There could be many reasons for this, but in most cases this is caused by heavy overselling of the disk space.
說白了，就是因為vps供應商，超額售賣vps虛擬機，宿主機上面已經沒有磁盤空間了。導致vps虛擬機的磁盤，也無法使用。至此問題終於被找到，接下來就是讓網友自己聯系vps供應商更換vps了。
總結：不能放過任何的蛛絲馬跡，有的時候故障不一定是自身引起的，要考慮具體的相關環境。
引用：http://www.webhostingtalk.com/showthread.php?t=1083184