ユーザーサービスファイルを使用してnginx podmanコンテナを起動することはできません。

ユーザーサービスファイルを使用して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

手動で実行すると正常に実行され、すべてのコンテナが起動します。起動時に実行するために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

これは答えの一部です。何かがSIGTERMをnginxに送っています。確認しましたドッカーファイルそして、目に見える健康診断やそれを殺すことができるものを見ないでください。

おかげで理解できます。便利な答え。私はhttpdコンテナで同じ動作を見て直観的にそれとnginxの両方を置き換えました--restart-always

この問題は他人に任せます。おそらくSIGTERMの原因が何であるかを調べることができます。

関連情報