在服务器启动docker容器卡住、无启动成功信息,docker ps一a状态码137

在服务器启动docker容器卡住、无启动成功信息,docker ps 一a状态码137

docker、ubuntu 20.04、emqx 5.8.0

背景

想从移动安卓设备往服务器发点数据,因为服务器有固定IP,想起来之前看过的这个mqtt,感觉比较合适,但是启动过程有点坎坷,本文记录其中一个问题。

问题描述

在服务器,使用emqx官网命令启动容器:

docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:5.8.0

然而中间卡住了,没有启动成功,服务也无法使用,启动日志如下:

WARNING: Default (insecure) Erlang cookie is in use.
2024-09-18T14:58:11.325377408Z WARNING: Configure node.cookie in /opt/emqx/etc/emqx.conf or override from environment variable EMQX_NODE__COOKIE
2024-09-18T14:58:11.325389391Z WARNING: NOTE: Use the same cookie for all nodes in the cluster.
2024-09-18T14:58:12.660521365Z EMQX_RPC__PORT_DISCOVERY [rpc.port_discovery]: manual
2024-09-18T14:58:12.660970597Z EMQX_NODE__NAME [node.name]: emqx@172.17.0.2

看警告提示,感觉会不会是cookie参数的问题,于是搜索后使用下面的命令启动容器:

docker run -e EMQX_NODE__COOKIE=com.linux.utunbu.docker.emqx -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:5.8.0

然而没有什么作用:

EMQX_RPC__PORT_DISCOVERY [rpc.port_discovery]: manual
2024-09-18T15:02:41.480356524Z EMQX_NODE__COOKIE [node.cookie]: ******
2024-09-18T15:02:41.480367517Z EMQX_NODE__NAME [node.name]: emqx@172.17.0.2

服务器有点卡,在虚拟机尝试启动:

docker run -e EMQX_NODE__COOKIE=com.linux.utunbu.docker.emqx -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:5.8.0

启动成功了,服务也可用,日志如下:

EMQX_RPC__PORT_DISCOVERY [rpc.port_discovery]: manual
EMQX_NODE__CoOKIE [node.cookie]: *****
EMQX_NODE__NAME [node.name]: emqx@172.17.0.2
Listener tcp:default on 0.0.0.0:1883 started.
Listener ssl:default on 0.0.0.0:8883 started.
Listener ws:default on 0.0.0.0:8083 started.
Listener wss:default on 0.0.0.0:8084 started.
Listener http:dashboard on :18083 started.
EMQx 5.8.0 is running now!

再次尝试使用官网命令,在虚拟机启动:

docker run -d --name emqx -p 1883:1883 -p 8083:8083 -p 8084:8084 -p 8883:8883 -p 18083:18083 emqx/emqx:5.8.0

启动成功,服务可用,日志同上。

原因分析

同样的docker版本,同样的系统版本,为什么虚拟机能行,服务器就不行了呢?

求助ai助手:

你好,我的emqx服务容器启动到这里就不动了,也没有报错退出也没有成功启动服务,但是容器也没有停止运行,请问这是怎么回事

(实际上容器是停止运行了,只是因为idea的服务插件没有刷新容器状态,所以我这里没有发现)

回答提到:

服务启动卡住:
你提到 EMQX 容器启动后没有报错退出,也没有成功启动服务,但容器仍在运行。这种情况通常有几个可能的原因:
配置问题:虽然直接的错误没有显示在日志中,但某些配置错误可能导致 EMQX 无法完全启动。检查 emqx.conf
和其他相关配置文件,确保所有必要的配置都已正确设置。
资源限制:容器可能由于资源限制(如 CPU、内存或磁盘空间)而无法完全启动。检查 Docker 容器的资源限制设置。
网络问题:如果 EMQX 需要访问外部服务(如数据库、认证服务等),网络问题可能导致启动过程卡住。
依赖服务未就绪:如果 EMQX 依赖于其他服务(如数据库服务),而这些服务在 EMQX 启动时尚未就绪,也可能导致启动卡住。

解决步骤
查看更详细的日志:
尝试增加日志级别,以获取更多关于启动过程的信息。
查看 Docker 容器的日志(使用 docker logs [容器ID或名称] 命令)。

检查资源限制:
查看 Docker 容器的资源使用情况,确保有足够的资源供 EMQX 使用。

提到两点:1. 日志;2. 资源限制

1.1. 使用docker logs ****没有发现有效信息
1.2. 使用外挂日志和数据,也没有有效信息:

docker run -d --name emqx -e ERL_FLAGS="+c false" -p 1883:1883 -p 8083:8083   -p 8084:8084 -p 8883:8883   -p 18083:18083   -v $PWD/data:/opt/emqx/data   -v $PWD/log:/opt/emqx/log   emqx/emqx:5.8.0

2.1. ssh工具显示内存使用了一半多,服务器运营平台显示内存512MB,是有点少,但是也是有200MB,理论上应该够用了才对。
但是,多次询问ai都提示我资源问题,使用docker ps -a 命令,显示容器是Exited (137) 14 minutes ago 的状态。

再次问询爱助手得:

当你遇到 Docker 容器启动后很快退出(状态为 Exited (137)),这通常意味着容器内的进程被系统强制终止了。状态码 137
通常与容器内的进程收到了 SIGKILL 信号(即被系统强制杀死)有关。这种情况可能由多种原因引起,但以下是一些可能的解释和排查步骤:

内存不足:
尽管你提到服务器资源空间还足够(可能是指磁盘空间),但内存不足也可能导致容器被杀死。你可以检查服务器的内存使用情况,特别是当
EMQX 启动时是否有大量的内存被其他进程占用。你可以使用 free -m 或 top 命令来查看内存使用情况。
OOM Killer(Out of Memory Killer):
如果系统内存不足,Linux 的 OOM Killer 会选择并杀死一些进程以释放内存。这通常发生在内存使用接近或超过物理内存和交换空间的总和时。你可以检查
/var/log/syslog 或 /var/log/messages(取决于你的系统配置)来查看是否有关于 OOM Killer 的日志条目。

Docker 配置:
检查 Docker 的内存限制设置。如果你为 Docker 容器设置了内存限制,并且这个限制太低,那么容器可能会因为超出限制而被杀死。你可以使用
docker inspect [容器ID或名称] 命令来查看容器的内存限制设置。

EMQX 配置问题:
尽管 EMQX 本身的配置问题不太可能导致容器被杀死(除非它导致了内存泄漏或类似的严重问题),但检查 emqx.conf
文件中的配置仍然是一个好主意。特别是与内存使用相关的配置,如缓存大小、消息队列大小等。

系统日志:
查看系统的日志文件,如 /var/log/syslog 或 /var/log/messages,以获取有关容器退出时系统状态的更多信息。

Docker 日志:
尽管你提到外挂的日志目录没有信息,但 Docker 本身的日志可能包含有关容器退出的有用信息。你可以使用 docker
logs [容器ID或名称] 命令来查看 Docker 容器的日志。
尝试不同的 Docker 镜像或版本:
如果可能,尝试使用不同版本的 EMQX Docker 镜像来查看问题是否仍然存在。
检查 Docker 守护进程和内核日志:
有时 Docker 守护进程或内核日志中会包含有关容器退出的更多详细信息。
逐步调试:
如果可能,尝试以非守护进程模式(即不带 -d 选项)运行容器,以便你可以看到容器的实时输出。这可能会提供有关为什么容器退出的更多线索。
联系支持:
如果上述步骤都无法解决问题,你可能需要联系 EMQX 的支持团队或 Docker 社区以获取帮助。
最后,请注意,即使你的本地 Ubuntu 20.04 虚拟机可以正常运行相同的命令,服务器环境也可能存在不同的配置或限制,这可能导致不同的行为。因此,在排查问题时,请务必考虑服务器环境的特定因素。

一个是提醒我检查配置文件(其实没有配置文件),再一个就是说,可以使用-m 32M --memory-swap 64M(搜索来的命令)限制容器空间。

使用这个命令限制最大空间为32MB,丢包严重,频率稍高就会丢失,显然不可用:

docker run -d -m 32M --memory-swap 64M --name emqx-min -e ERL_FLAGS="+c false" -p 1893:1883 -p 8093:8083 -p 8094:8084 -p 8893:8883 -p 18093:18083 emqx/emqx:5.8.0

使用这个命令限制最大空间为64MB,频率特别高的时候也会丢失,管理控制台的刷新率同样降频了,但丢包率比32MB大大降低了:

docker run -d -m 64M --memory-swap 128M --name emqx-min -e ERL_FLAGS="+c false" -p 1893:1883 -p 8093:8083 -p 8094:8084 -p 8893:8883 -p 18093:18083 emqx/emqx:5.8.0

然而,然而64MB的容器启动了半天,卡了半天,终究还是死了,这说明服务器不可能运行这个mqtt的服务了。

解决方案

既然如此,我觉得就只能尝试,在服务器转发所有网络请求,到我的电脑上;在我的电脑上运行服务,处理请求了

声明:本文使用八爪鱼rpa工具从gitee自动搬运本人原创(或摘录,会备注出处)博客,如版式错乱请评论私信,如情况紧急或久未回复请致邮 xkm.0jiejie0@qq.com 并备注原委;引用本人笔记的链接正常情况下均可访问,如打不开请查看该链接末尾的笔记标题(右击链接文本,点击 复制链接地址,在文本编辑工具粘贴查看,也可在搜索框粘贴后直接编辑然后搜索),在本人博客手动搜索该标题即可;如遇任何问题,或有更佳方案,欢迎与我沟通!

上一篇:腾讯云视频文件上传云存储时自动将mp4格式转码成m3u8


下一篇:RISC-V笔记——代码移植指南-4. Arm操作映射