1

4

开 ssh ，让我上去看看

2

1

你 docker 运行的不是提供服务本身的那个进程吧？

5

2

有没有可能你服务的进程不是 0 号？这种情况它异常退出后 docker 是不知道

6

1

多半是自己程序的 bug ，异常终止了。docker logs 的输出内容是可以通过程序修改的，所以如果程序自己崩了，没有弹出异常，docker 容器也不知道发生了什么。检查一下程序有没有 bug 吧。

7

@klo424 目前初步怀疑确实是程序本身的问题，但因为不好排查所以无法判断，而且同一个版本下使用 Windows 的二进制运行的没有出现过类似的问题

8

@log4j 看了下，服务本身确实不是 0 号进程，0 号进程是一个启动脚本。那就更可能是服务本身出现了问题。

10

写个定时任务，每晚重启下 docker 服务，先跑着

13

dockerfile 有问题吧，就像楼上说的不是 0 号进程

15

盲猜 dockerfile 有问题，容器内启动的进程不是 0 导致即使服务挂了 docker 也认为没有问题一切正常

16

这就是为什么 Docker 推荐一个容器一个进程，即使多个进程也要有成熟的进程管理工具。

17

你有请求日志吧？把那些重放一遍看能重现出来不，不然等 2-3 周实在没法弄

18

脚本中启动服务的命令是用的 exec 么?

19

如果把容器实例当成物理宿主机，虽然里面的服务进程挂起，但物理宿主机是仍然在运行的，因此你用 docker ps 显示容器实例正在运行，是正常现象。至于 docker log 无输出，是因为 docker log 可能绑定到服务进程的 log 输出，由于服务进程挂起，无 log 输出，所以你用 docker log 也无输出了。

21

@johnbobby dockerfile 没有改动过，之前从来没遇到过这种问题。

24

1

保留现场，根据是什么语言，用相应工具提取一下 stack 看看卡在哪里了。
软件 bug 很常见的，特别是有些异常输入之类的。大概率不是 docker 的问题。
你要保证可用性，建议前面加个负载均衡之类的服务，这样一个停了，可以直接启动另外一个，然后分析前一个的状态。

25

多数是服务停了，但是启动服务的 shell 还活着。在等待控制台的输入。

26

从来都是 pid=1 的进程吧，0 号进程是什么

27

@c4923 脚本里面用 exec 启动服务，pid=1 的就是你的服务进程。执行 docker ps 看状态是 up ，那说明 pid=1 还活着。 用 docker exec 进容器执行 ps -p 1 -o stat,rss,vsz,cmd,wchan 看进程状态如何呢

28

大概率是服务程序的代码 bug ，或者程序引入模块的 bug 。有些服务架构是有外部调用多少次就重启一个新进程，可以规避长时间运行不稳定的情况。

29

我猜你是用脚本启动的服务进程然后在脚本里做了无限等待吧