本文為php中文網認證作者：“齊天大圣”投稿，歡迎加入php中文網有償投稿計劃！
事情經過
昨天早上，打開電腦發現自己的博客網站打開不了，準備遠程登錄服務器查看問題，發現服務器遠程不上。沒辦法，登錄阿里云后臺，重啟服務器。重啟完成后，網站能正常打開，所以當時就不以為然，以為阿里云那邊是不是出了什么毛病。
到了下午的時候，發現網站又打不開了，而且又遠程連接不了服務器。進入阿里云控制臺，查看監控發現cpu跑滿了。只能再重啟服務器，等重啟完成后再遠程連接上去，這次需要好好排查問題。
解決問題
當時首先想到的是中病毒了，先不管那么多，第一步是找到那些耗cpu的進程殺死。使用top命令，查看耗cpu的進程有哪些。一看就明白了，都是bzip2搞得鬼。
殺進程的過程發現一個問題，就是這些進程殺死了，過一會又出現了。這種現象，我知道肯定要找到他們的父進程，擒賊先擒王。
# ps -lA | grep bzip2
0 R 0 1965 1964 44 80 0 - 3435 - ? 00:01:43 bzip2
0 S 0 1981 1980 33 80 0 - 3435 pipe_w ? 00:00:56 bzip2
0 R 0 1997 1996 30 80 0 - 3435 - ? 00:00:31 bzip2
0 R 0 2013 2012 27 80 0 - 3435 - ? 00:00:07 bzip2
0 R 0 2024 2023 15 80 0 - 3435 - ? 00:00:00 bzip2
但是發現他們的ppid不是同一個，這就讓我很疑惑了。我打算用進程樹看看
pstree -up
這時候，我就知道了，原來是自己的定時腳本有問題。那么我需要做以下幾件事：
- 關閉crond服務
- crontab -e 將weekly.sh去掉
- 殺掉那些耗cpu的進程
# 關閉
[root@iz8vb626ci0aehwsivxaydz ~]# kill 1622
[root@iz8vb626ci0aehwsivxaydz ~]# systemctl status crond
● crond.service - Command Scheduler
Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Tue 2019-11-12 10:44:32 CST; 10s ago
Main PID: 1622 (code=exited, status=0/SUCCESS)
# 修改crontab -e
# 殺掉耗cpu進程，下面的命令執行了好幾遍，才將所有耗cpu進程全部殺掉了
ps -lA | grep bzip2 | awk '{print $4}' | xargs -n 10 kill -9
問題原因與思考
剛開始，我以為是自己的shell腳本有問題，出現死循環導致問題出現。但是查看腳本，發現沒有問題，沒有死循環的情況出現。一時間，百思不得姐。
#!/bin/bash
# 每周備份腳本
export PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin
export
backdir=/backup/weekly # 備份目錄
[ -z "$backdir" ] || mkdir -p $backdir
dirs=(/etc /home /root /usr /var/spool/cron /var/spool/at) # 需要備份的目錄
for dir in ${dirs[@]}
do
if [ ! -d $dir ];then
continue
fi
cd $backdir
tar -jcpf $(basename $dir)_$(date +%Y%m%d).tar.bz2 $dir
done
# 刪除mtime大于30天的文件
find $backdir -mtime +30 -name *.tar.bz2 -exec rm -f {} ;
過了很長時間，終于找到了原因所在，原來是自己的定時任務寫法有問題
* 3 * * 1 /root/bin/weekly.sh 1>/dev/null 2>&1
我原本的想法是每周1凌晨3點執行一次備份腳本，但是這樣寫的結果是每周一凌晨3點的每分鐘都會執行該腳本一次。正確的寫法應該如下：
# 每周一凌晨三點零一分執行該腳本
1 3 * * 1 /root/bin/weekly.sh 1>/dev/null 2>&1
問題解決了，原因也找到了。自己該寫一個服務器資源監控腳本了。
