主页 / 问题 / 1254267
Accepted
Total Pusher
Asked:2022-03-11 05:33:59 +0000 UTC2022-03-11 05:33:59 +0000 UTC

使用 PHP 控制台重启 docker 容器

  • 772

有时我需要强制一个进程重新读取它的配置，或者如果它是一个脚本，它的源代码。

我该怎么做：

  • Nginx: docker-compose exec nginx sh -c 'nginx -s reload'- Nginx 对此有一个特殊的信号
  • 无界：docker-compose exec dns sh -c 'unbound-control reload'
  • php-fpm: docker-compose exec php-fpm sh -c 'kill 1'- 只需杀死进程 PID 1 并docker-compose.yml设置重启策略restart: always，以便容器重启

等等。如果没有提供重读，那么它会有所帮助kill 1。

在这里我遇到了难以理解的行为：kill 1它不起作用。所以，按顺序。

有一个 docker 容器，其中执行控制台命令php /var/www/artisan queue:work --sleep=1，它保持与 Redis 的连接并处理队列。

我在这个容器中执行kill 1，没有任何反应。程序本身继续成功处理队列。

ps aux：

USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.1  0.1 183592 50544 ?        Ss   19:11   0:10 php /var/www/artisan queue:work --sleep=1

为什么会出现这样的情况？因为等待 I/O？还是忽略信号？

PS。当然，我可以使用 docker 重启容器。但我想知道为什么会这样。

php

1 个回答

  1. Best Answer

    kill默认发送SIGTERM，可以被进程自己拦截并忽略。这可能就是正在发生的事情。一段时间后可以发送SIGKILL，不能被拦截（kill -9 1）

    他们也有错误，所以值得检查你的版本

    https://divinglaravel.com/queue-workers-how-they-work

    当然，我可以使用 docker 重启容器。但我想知道为什么会这样。

    顺便说一句，这将是最正确的，因为它docker stop会先发送SIGTERM，然后SIGKILL。

    从文档https://docs.docker.com/engine/reference/commandline/stop/

    容器内的主进程将收到 SIGTERM，并在宽限期后收到 SIGKILL。

    • 3

相关问题