简体繁体 English

Elasticsearch Docker停止似乎忽略了SIGKILL

[英]Elasticsearch Docker stop seems to ignore SIGKILL

原文 2017-04-01 14:30:05 1 1 elasticsearch/ docker

I'm trying to use Elasticsearch in Docker for local dev. 我正在尝试在Docker中将Elasticsearch用于本地开发人员。 While I can find containers that work, when docker stop is sent, the containers hang for the default 10s, then docker forcibly kills the container. 虽然我可以找到可以使用的容器，但在发送docker stop时，容器会挂起默认10秒钟，然后docker强制杀死了该容器。 My assumption here is that ES is either not on PID 1 or other services prevent it from shutting down immediately. 我在这里的假设是，ES不在PID 1上，或者其他服务阻止ES立即关闭。

I'm curious if anyone can expand on this, or explain why this is happening more accurately. 我很好奇是否有人可以对此进行扩展，或者解释为什么这种情况会更准确地发生。 I'm running numerous tests and 10s+ to shutdown is just annoying when other containers shutdown after 1-2s. 我正在运行大量测试，并且当其他容器在1-2秒后关闭时，令人讨厌的是10s +才关闭。

1 个解决方案

If you don't want to wait the 10 seconds, you can run a docker kill instead of a docker stop . 如果您不想等待10秒，则可以运行docker kill而不是docker stop 。 You can also adjust the timeout on docker stop with the -t option, eg docker stop -t 2 $container_id to only wait 2 seconds instead of the default 10. 您也可以使用-t选项调整docker stop的超时，例如docker stop -t 2 $container_id仅等待2秒，而不是默认的10秒。

As for why it's ignoring the sigkill, that may depend on what image you are running (there's more than one for elasticsearch). 至于为什么它会忽略sigkill，这可能取决于您正在运行的图像（elasticsearch有多个图像）。 However, if pid 1 is a shell like /bin/sh or /bin/bash, it will not pass signals through. 但是，如果pid 1是像/ bin / sh或/ bin / bash这样的shell，它将不会传递信号。 If pid 1 is the elasticsearch process, it may ignore the signal, or 10 seconds may not be long enough for it to fully cleanup and shutdown. 如果pid 1是elasticsearch进程，则它可能会忽略该信号，或者10秒可能不够长，无法完全清除和关闭该信号。