☰

无法使用用户服务文件启动 nginx podman 容器

tag-icon • tag-icon systemd container podman systemd-user
无法使用用户服务文件启动 nginx podman 容器

我有一个作为服务的一部分运行的 nginx 容器。这是用于启动包括nginx在内的所有容器的函数代码：

    if [[ ! -s ${SCRIPT_DIR}/.container-info-patches.txt ]]; then
      patches_echo "Patches must be set up before running. Please run 'patches setup' first."
      exit 1
    fi

    all_containers_running=false

    while true; do
      all_containers_running=true

      for container in "${containers[@]}"; do
        patches_echo "Checking container status: $container"
        status=$(podman container inspect -f '{{.State.Status}}' "$container" 2>/dev/null)

        if [[ "$status" != "running" ]]; then
          all_containers_running=false

          patches_echo "Starting container: $container"
          podman start "$container" >/dev/null 2>&1 || patches_echo "Container not found: $container" --error

          if [[ $container == "patches-nginx" ]]; then
            check_nginx_status
          elif [[ $container == "patches-psql" ]]; then
            wait_for_postgresql
          fi
        fi
      done

      if [[ $all_containers_running == "true" ]]; then
        break
      fi

      if [[ $CONTINUOUS != "TRUE" ]]; then
        break
      fi

      sleep 1
    done

如果我手动运行它，它运行得很好并且所有容器都会启动。我有一个用户 systemd 文件，我已使用 linger 设置该文件以在启动时运行。它启动所有容器除了nginx没有问题。当我podman logs patches-nginx重新启动后检查日志时，我看到：

}[grant@patches ~]$podman logs patches-nginx
/docker-entrypoint.sh: /docker-entrypoint.d/ is not empty, will attempt to perform configuration
/docker-entrypoint.sh: Looking for shell scripts in /docker-entrypoint.d/
/docker-entrypoint.sh: Launching /docker-entrypoint.d/10-listen-on-ipv6-by-default.sh
10-listen-on-ipv6-by-default.sh: info: IPv6 listen already enabled
/docker-entrypoint.sh: Launching /docker-entrypoint.d/20-envsubst-on-templates.sh
/docker-entrypoint.sh: Launching /docker-entrypoint.d/30-tune-worker-processes.sh
/docker-entrypoint.sh: Configuration complete; ready for start up

        10.89.0.5 - - [02/Jun/2023:18:48:43 +0000]
        "GET / HTTP/1.1" 400 255
        "-" "curl/7.76.1"
        Certificate: "-"
        Client Key: "-"

这告诉我除了它收到一个发出 400 的单个请求之外，它还很高兴，并且没有理由退出。即使它确实退出了，我还专门设计了前面提到的启动功能，以连续重试启动nginx 60秒。绝对奇怪的是，代码退出并忽略了在 60 秒窗口下方继续尝试启动它的代码。

同样，如果我运行与服务文件应手动运行的代码完全相同的代码，则一切都将完全按照我的预期运行。也就是说，如果我登录并运行，patches.sh start --continuous所有内容都会立即出现，包括 nginx，这表面上是服务文件应该做的所有事情。

有关服务文件的某些内容搞乱了工作，我无法弄清楚它是什么，因为一切除了nginx 完全按照预期工作。

服务文件很简单：

[Unit]
Description=Patches Service
Wants=network.target
After=network.target
Requires=user@${USER}.service

[Service]
Type=oneshot
TimeoutStartSec=10min
ExecStart=/bin/bash ${SCRIPT_DIR}/patches.sh start --continuous

[Install]
WantedBy=default.target

答案1

这是答案的一部分 - 有东西正在向 nginx 发送 SIGTERM。我检查了docker文件并且没有看到任何突出的健康检查或可能会杀死它的东西。

多亏了这个我才明白了有帮助的答案。我在 httpd 容器上看到了相同的行为，并凭直觉将它和 nginx 都交换到了，--restart-always现在它们都可以工作了。

我将把这个问题留给其他人，也许他们会来找出导致 SIGTERM 的原因。

相关内容