节约时间，先说原因吧。是中了挖矿木马脚本。

处理

删除脚本

进到目录下

    cd /tmp/到木马脚本的路径
    rm -rf *

清除定时任务

    crontab -u git -l  # 列出git用户的所有定时任务
    crontab -u git -e  # 编辑定时任务,进去后清空异常定时任务.正常是没有定时任务的.

kill运行中的脚本

杀掉运行中的任务

    ps aux | egrep "^git "		# 查看git用户运行的进程,记下异常进程编号
    kill -9 进程编号1 进程编号2 ...	# 杀死异常进程.

排查经过

2.10，L君反馈gitlab服务器卡，我第一反应是磁盘是不是又满了？ 赶紧ssh连上去看了，df -h磁盘使用50%不到。 于是先后free、top看了一遍。 top时，看到了一个"git程序"的执行的进程"exe"占用cpu非常高。于是将其kill掉了，并重启了一遍服务。(实际这里是"git"用户,而不是"git"程序,当时看错以为是父进程"git") 而后L君反映虽然还是有点卡，但比之前好很多了。 我以为是刚重启，启动服务是有点卡于是以为正常了，继续搞其他工作了。

2.11, 再次收到L君反馈,合并项目一直在转圈圈，半个小时了没有成功。 这次不假思索,又一次上去,看了进程,果然,一个git用户的 system-dev 进程150%的cpu占用. 考虑昨天刚kill过,于是重启服务器. 重启完毕之后,问题依然存在. system-dev 又占了cpu了. 百度+谷歌一圈之后,没找到这个gitlab有这个进程的信息. 于是看 ps 查看了相关进程的信息,发现在 /tmp/... 目录下,打开同目录下的几个脚本看了一遍,发现有些异常,特别config.json里面的ip(94.23.247.226:443)应该是海外的ip. 浏览器打开 https://94.23.247.226 页面直接显示是 “Mining Pool Online”(在线矿池) 。 答案很明显了，应该是中了挖矿木马了。 于是谷歌的相关处理方法，把目录下的所有脚本都清了一遍，并且清了"git"用户的定时任务。(这些个脚本5分钟执行一次)

清完之后重启gitlab问题依然还存在,合并不了项目. 原以为是被破坏了一些配置文件.但是除了job不执行,其他一切正常. 最后是想起来可能还有残留脚本没有kill. ps 一下果然如此. kill掉运行中的脚本之后,再次检查脚本目录确认没有重新生成.然后把gitlab重启了. 这次可以合并了.