在服务器启动docker容器卡住、无启动成功信息
想从移动安卓设备往服务器发点数据,因为服务器有固定IP,想起来之前看过的这个mqtt,感觉比较合适,但是启动过程有点坎坷,本文记录其中一个问题。
在服务器,使用emqx官网命令启动容器:
然而中间卡住了,没有启动成功,服务也无法使用,启动日志如下:
看警告提示,感觉会不会是cookie参数的问题,于是搜索后使用下面的命令启动容器:
然而没有什么作用:
服务器有点卡,在虚拟机尝试启动:
启动成功了,服务也可用,日志如下:
再次尝试使用官网命令,在虚拟机启动:
启动成功,服务可用,日志同上。
同样的版本,同样的系统版本,为什么虚拟机能行,服务器就不行了呢?
求助ai助手:
你好,我的emqx服务容器启动到这里就不动了,也没有报错退出也没有成功启动服务,但是容器也没有停止运行,请问这是怎么回事
(实际上容器是停止运行了,只是因为idea的服务插件没有刷新容器状态,所以我这里没有发现)
回答提到:
服务启动卡住:
你提到 EMQX 容器启动后没有报错退出,也没有成功启动服务,但容器仍在运行。这种情况通常有几个可能的原因:
配置问题:虽然直接的错误没有显示在日志中,但某些配置错误可能导致 EMQX 无法完全启动。检查 emqx.conf
和其他相关配置文件,确保所有必要的配置都已正确设置。
资源限制:容器可能由于资源限制(如 CPU、内存或磁盘空间)而无法完全启动。检查 Docker 容器的资源限制设置。
网络问题:如果 EMQX 需要访问外部服务(如数据库、认证服务等),网络问题可能导致启动过程卡住。
依赖服务未就绪:如果 EMQX 依赖于其他服务(如数据库服务),而这些服务在 EMQX 启动时尚未就绪,也可能导致启动卡住。解决步骤
查看更详细的日志:
尝试增加日志级别,以获取更多关于启动过程的信息。
查看 Docker 容器的日志(使用 logs [容器ID或名称] 命令)。检查资源限制:
查看 Docker 容器的资源使用情况,确保有足够的资源供 EMQX 使用。
提到两点:1. 日志;2. 资源限制
1.1. 使用没有发现有效信息
1.2. 使用外挂日志和数据,也没有有效信息:
2.1. ssh工具显示内存使用了一半多,服务器运营平台显示内存512MB,是有点少,但是也是有200MB,理论上应该够用了才对。
但是,多次询问ai都提示我资源问题,使用 命令,显示容器是 的状态。
再次问询爱助手得:
当你遇到 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 容器设置了内存限制,并且这个限制太低,那么容器可能会因为超出限制而被杀死。你可以使用
inspect [容器ID或名称] 命令来查看容器的内存限制设置。EMQX 配置问题:
尽管 EMQX 本身的配置问题不太可能导致容器被杀死(除非它导致了内存泄漏或类似的严重问题),但检查 emqx.conf
文件中的配置仍然是一个好主意。特别是与内存使用相关的配置,如缓存大小、消息队列大小等。系统日志:
查看系统的日志文件,如 /var/log/syslog 或 /var/log/messages,以获取有关容器退出时系统状态的更多信息。Docker 日志:
尽管你提到外挂的日志目录没有信息,但 Docker 本身的日志可能包含有关容器退出的有用信息。你可以使用
logs [容器ID或名称] 命令来查看 Docker 容器的日志。
尝试不同的 Docker 镜像或版本:
如果可能,尝试使用不同版本的 EMQX Docker 镜像来查看问题是否仍然存在。
检查 Docker 守护进程和内核日志:
有时 Docker 守护进程或内核日志中会包含有关容器退出的更多详细信息。
逐步调试:
如果可能,尝试以非守护进程模式(即不带 -d 选项)运行容器,以便你可以看到容器的实时输出。这可能会提供有关为什么容器退出的更多线索。
联系支持:
如果上述步骤都无法解决问题,你可能需要联系 EMQX 的支持团队或 Docker 社区以获取帮助。
最后,请注意,即使你的本地 Ubuntu 20.04 虚拟机可以正常运行相同的命令,服务器环境也可能存在不同的配置或限制,这可能导致不同的行为。因此,在排查问题时,请务必考虑服务器环境的特定因素。
一个是提醒我检查配置文件(其实没有配置文件),再一个就是说,可以使用(搜索来的命令)限制容器空间。
使用这个命令限制最大空间为32MB,丢包严重,频率稍高就会丢失,显然不可用:
使用这个命令限制最大空间为64MB,频率特别高的时候也会丢失,管理控制台的刷新率同样降频了,但丢包率比32MB大大降低了:
然而,然而64MB的容器启动了半天,卡了半天,终究还是死了,这说明服务器不可能运行这个mqtt的服务了。
既然如此,我觉得就只能尝试,在服务器转发所有网络请求,到我的电脑上;在我的电脑上运行服务,处理请求了
声明:本文使用八爪鱼rpa工具从gitee自动搬运本人原创(或摘录,会备注出处)博客,如版式错乱请评论私信,如情况紧急或久未回复请致邮 xkm.0jiejie0@qq.com 并备注原委;引用本人笔记的链接正常情况下均可访问,如打不开请查看该链接末尾的笔记标题(右击链接文本,点击 复制链接地址,在文本编辑工具粘贴查看,也可在搜索框粘贴后直接编辑然后搜索),在本人博客手动搜索该标题即可;如遇任何问题,或有更佳方案,欢迎与我沟通!
<< 上一篇
下一篇 >>