最近在ubuntu服務器上跑深度學習的訓練程式，運行一段時間程式就會被kill，給實驗帶來了不少麻煩，作為linux小白，著實是被這個問題困擾了一段時間，現將最后成功的方法記錄下來，
關于這類問題，最常見的原因是系統記憶體不足，觸發了OOM killer，于是先用htop查看系統的資源使用情況：
發現系統記憶體仍然是充足的，但是所有CPU核心都是100%占用，所以應該不是記憶體不足的問題，而是因為CPU爆滿了，CPU主要是被一批“python”行程占用了，盡管這批行程的啟動命令都顯示為“python”，但沒有引數，看起來不像正常的程式，用kill -9命令殺死這些行程，發現過一段時間又會重新出現，由于服務器之前中過挖礦病毒，所以這次也懷疑是中了挖礦病毒，
用 “ll /proc/行程ID” 查看行程資訊（由于中間曾經殺死過行程，這里截的兩張圖的行程ID號不同）：
發現行程是由/usr/bin/-bash檔案啟動的，且該檔案已被洗掉，可以猜測這個檔案只是一個臨時檔案，不是真正的病毒檔案，這個路徑可能也是臨時的，真正的病毒檔案可能每次會隨機選擇一個目錄生成臨時檔案，啟動行程后再把臨時檔案洗掉，以便隱藏自己，
由于這些行程被殺死后又會重新出現，所以懷疑其背后還有守護行程或者定時任務，首先查看系統的定時任務，ubuntu的/etc目錄下有cron.weekly、cron.daily、cron.hourly等存放定時任務的檔案夾，由于上述例外行程被殺死后不到一小時又重新出現，所以先查看cron.hourly，進入/etc/cron.hourly，查看目前都有哪些定時腳本：
發現里面只有一個sync，用vim打開看看其中的內容：
看到腳本中有/usr/bin/-bash，正是被例外行程洗掉掉的檔案名，看來這個腳本是跟例外行程有關系的，感覺找對了，再看第一行是cp … /bin/sysdrr /usr/bin/-bash …，似乎是把/bin/sysdrr復制為/usr/bin/-bash，接著看下面幾行，似乎分別是“進入/usr/bin”，“啟動-bash檔案”、“洗掉-bash檔案”的意思，如果按照這個理解，病毒行程的啟動流程就與之前的猜測一樣，但/bin/sysdrr也不一定是真正的病毒檔案，可能只是比/usr/bin/-bash更高一級的存在，
為了確定/bin/sysdrr是不是也是一個臨時檔案，進入/bin目錄，看看該檔案是否還存在，結果發現該檔案沒有被洗掉，也許這個就是真正的病毒檔案？如果是的話把這個檔案刪掉就可以了，但不確定前面的猜測是否正確，即使前面猜測正確了，也不確定是否還有其他的病毒檔案，不過，如果這個是病毒檔案的話，也許別人也曾遇到過，于是先在網上搜索一下，直接搜索sysdrr：
好家伙，還真有相關的結果，看來確實是挖礦病毒，看了其中幾個結果，發現跟我遇到的情況非常相似，看來前面的猜測基本沒錯，在其中幾個搜索結果里，都是說把/bin/sysdrr刪掉，順便清理掉定時腳本就可以了，姑且認為/bin/sysdrr就是真正的病毒檔案，背后沒有其他的病毒檔案存在了，于是參考搜索結果里的做法，洗掉/bin/sysdrr（該檔案是只讀的，需要用chattr修改屬性才能洗掉），再清理掉定時腳本sync，sync在多個目錄下都存在：
查看一下這幾個目錄下的sync腳本，確定內容都一樣后，便可以放心地將這些sync腳本全部清除了，
最后用kill -9命令把例外行程殺死，幾個小時后仍然沒有重新啟動（平時過幾十分鐘就會重新啟動），也許這次的問題已經解決了，
但目前仍不確定服務器是怎么被病毒入侵的，如果入侵的途徑沒有封上，以后還有可能再次中病毒，后續還需要加強服務器的安全措施，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/282718.html
標籤：其他
上一篇：記一次面試經歷