Linux系统下使用dockercompose部署的stringboot应用程序不断重启，无法正常访问。

Linux系统下使用dockercompose部署的stringboot应用程序不断重启，无法正常访问。

问题描述

使用dockercompose部署的stringboot应用程序，每次都是启动成功，通过apifox访问接口就失败，端口也无法ping通。没有任何报错信息，启动日志也不全，只有2行。

最开始定位的是stringboot的版本号问题，原本使用的是2.2版本，后来更新到2.5.15，版本升级以后有所改善，启动日志起码是完整的了，我们发现系统一直在不断地重启，低概率可以ping通端口，6次里面有一次成功。至此掉进坑了，一直在检查程序的依赖配置问题。

后续我们换了3台不同环境的虚拟机进行测试，脚本一致的情况下都是可以正常发布的。mobaXterm监控系统的运行内存也是足够了，还有1.7G。

问题解决

最后我决定检查服务器本身是否存在问题，通过检查发现了一个进程占用了大量cpu，杀掉以后还会重启，cpu使用率一直高达98%,至此初步判断stringboot无法启动是因为cpu已经没有多余的空间运行程序了，现在要解决的就是杀掉这个没有见过的进程，保证cpu运行空间充足的情况下，重新发布软件。

具体操作

top 查看cpu占用情况

查看定时任务

用root 用户执行 crontab -l 查看死否存在定时任务，如果存在不认识的，统统删除 crontab -r

查看程序位置

通过 top 命令，我们可以知道这个 syst3md 的进程 PID 为 1818024 所以我们执行 ls -l /proc/1818024/exe

[root@Xiang ~]# ls -l /proc/1818024/exe
lrwxrwxrwx 1 lighthouse lighthouse 0 Nov 17 09:27 /proc/1818024/exe -> /tmp/.../syst3md

这个地方就很狡诈了，因为路径中带有 “…" 我原本以为这个文件 在 tmp 路径下的多层级文件夹内，用 find 命令在 tmp 下找半天，也还是 /tmp/.../syst3md 这个结果，原来，黑客在创建文件夹的时候，文件夹名就叫 ...

进入到程序路径，把这些文件都干掉

rm -rf /tmp/.../

杀进程

kill -9 1818024

执行完立竿见影

其他问题

无法删除syst3md文件

出现无法删除的情况，一般是文件的权限被i属性影响，所以我们需要先取消文件权限再删除。操作如下：

既然chattr是直接改变的文件属性，那么我们要排查是否是chattr授权的影响，那么就要查看所要操作的文件的权限了，这时候我们要用到lsattr这个命令
lsattr 用于显示文件属性，针对于我之前的报错，具体解决如下：

1. lsattr 查看该文件属性，我这个是直接查看当前路径下的所有文件属性.(如果要查特定文件，在后面加上文件属性即可。

如上图所示，authorized_keys文件多了一个”i”属性，i代表不得随意更改该文件或目录。这也就解释了为什么之前root用户下无法删除的原因。

2. chattr去i属性，既然查明了是受i属性的影响，那就把i去掉。操作命令：chattr -i ./authorized_keys

3. 复查一下文件属性，命令lsattr,发现果然i属性被去除了。

4. 执行操作，这时候我来执行原本想执行的操作，删除目标文件,命令rm authorized_keys

（5）检查一下，成功，命令ls发现当前目录下已经没有了authorized_keys，操作成功!

程序的最终发布脚本

Dockerfile

FROM ibmcom/ibmjava:8-sdk
COPY *.jar /app.jar
EXPOSE 80
ENV JAVA_TOOL_OPTIONS="-Xmx256m -Xms64m"
ENV JAVA_OPTS="-Xmx256m -Xms64m -XX:+UseParallelGC -Xtune:virtualized -Xshareclasses:cacheDir=/opt/shareclasses -Xjit:default"
ENTRYPOINT ["java","-jar","app.jar"]

dockercompose

version: '3.3'
services:
  authcenter:
    build:
      context: $PWD
      dockerfile: $PWD/Dockerfile
    image: website-api
    ports:
      - 8555:8888/tcp
    container_name: "website-api"
    restart: always

相关文章链接

【报错！】Root用户下删除文件失败rm: cannot remove ‘[文件名]’: Operation not permitted

syst3md矿机病毒及解决办法