今早ssh连接内网堡垒机发现连接失败,网页端端登录502,怀疑是frp的程序错误,就想直接ssh登录堡垒机宿主重启frpc,发现ssh直接登录也是连接失败,感觉事情不对劲,于是赶紧登录VCenter发现服务器CPU利用率已经100%,这明显不对劲我只能手动强制重启服务器,重启后登录时感觉有点慢以为是docker在启动堡垒机容器就没在意,结果过了一阵cpu利用率又上去了,通过ps命令发现大量frpc进程,于是通过命令:
ps -ef | grep frpc | grep -v grep | wc -l
统计出大概580多个frpc进程,怀疑我之前编写的frpc的启动文件有问题,趁服务器还没死透先让frpc禁止开机启动(之前已经写入service,可通过systemctl控制),再次手动重启服务器,重新启动后发现依然有大量frpc进程,我赶快去把frpc的启动文件改了名字,发现进程没有再增长,通过命令:
ps aux|grep frpc|grep -v grep|cut -c 9-15|xargs kill -15
#“ps aux”是linux 里查看所有进程的命令。这时检索出的进程将作为下一条命令“grep python”的输入。
#“grep frpc”的输出结果是,所有含有关键字“frpc”的进程,这是frpc程序
#“grep -v grep”是在列出的进程中去除含有关键字“grep”的进程
#“cut -c 9-15”是截取输入行的第9个字符到第15个字符,而这正好是进程号PID
#“xargs kill -15”中的xargs命令是用来把前面命令的输出结果(PID)作为“kill -15”命令的参数,并执行该令
#“kill -15”会正常退出指定进程,-9强行杀掉
批量杀死所有frpc进程后,ps命令看到有个进程提示找不到frpc启动文件,终于找到罪魁祸首了,经过排查发现是通过supervise做了守护进程,这个进程发现frpc没有启动就会进行一次重启,可能是脚本出现问题或者是我更改了systemctl启动,导致脚本程序检测不到frpc已经启动了,所以不停的启动frpc进程,于是我停止了supervise的母程序Daemontools,删除脚本文件,再次启动frpc,发现已经没有异常进程了
到此为止,异常解除,cpu负载也已经回归正常