---
title: トラブルシューティング
description: OpenLM LicOps でよく見られる症状とその意味。Router が LicOps モードにならない場合から、ジョブが拒否される場合や LicOps の判断をまったく経由しない場合までを扱います。
product: OpenLM Platform
---

目に見える症状から調べてください。LicOps の問題のほとんどは、LicOps が OpenLM Platform と同期していない、Router が LicOps モードで動作していない、リクエストが存在しないプールを指定している、ジョブが実際には LicOps を経由していない、の 4 つのいずれかです。

## コンテナーが起動しないのはなぜですか

LicOps は OpenLM Router 上で動作するため、起動時に失敗する原因はフェイルオーバー用の Router と同じです。接続文字列の変数名の誤り、相関モードの設定の欠落、2 回エンコードされた暗号化キーなどです。Router のトラブルシューティングの[コンテナーが起動しない](https://www.openlm.com/documentation/ja/cloud/deployment-operations/router/troubleshooting/#router-のコンテナーが起動しないのはなぜですか)を参照してください。次の表に、症状、原因、対処を示します。

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| Router は起動するが、すべての admit が失敗し、ログに admit 時の Redis エラーが記録される。 | Redis のバージョンが 7.0 より古いです。 | Redis を 7.0 以降にアップグレードします。[システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/system-requirements#redis-の要件)を参照してください。 |
| Kubernetes で Router が起動を拒否し、ログに `TrustedCidrs` が出力される。 | 信頼済みの範囲が空です。 | `routerapi.admissionController.proxyProtocol.trustedCidrs` に Pod の CIDR を設定します。[Kubernetes にデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deploy-kubernetes#router-をインストールする)を参照してください。 |
| Kubernetes で、末尾がコロンで終わるイメージ参照によってイメージのプルが失敗する。 | チャートの `tag` が設定されていません。 | すべてのタグを明示的に設定します。 |
| Kubernetes で、Webhook の Pod が `ImagePullBackOff` で失敗する。 | イメージ名またはタグが誤っています。 | OpenLM のバンドルに含まれるチャートを使用します。これらのチャートは `olm-pod-sidecar`、`olm-dispatch-init`、`olm-iptables-init` を指定しています。 |

## LicOps が OpenLM Platform と同期しないのはなぜですか

LicOps は Platform と同期するまで構成もルールもプールも持たないため、すべてのリクエストを拒否するか、受け付けません。Router UI の **Platform Connection** の下に理由を示す赤い通知が表示され、`GET /api/v1/status` も同じ理由を `configurationManagement.lastSync.lastFailure` で報告します。原因と対処はフェイルオーバー用の Router と同じです。[Router が Platform と同期しないのはなぜですか](https://www.openlm.com/documentation/ja/cloud/deployment-operations/router/troubleshooting/#router-が-openlm-platform-と同期しないのはなぜですか)を参照してください。

LicOps には最新のシート数とサーバーヘルスも必要で、これらは構成とは別に収集されます。確認するには、可用性レポートを読みます。

```bash
curl -s http://localhost:8100/api/v1/admission-controller/availability \
  | jq '{lastPlatformSyncTime, lastReconcileTime, coldStart, staleForAdmission}'
```

次の表に、症状、原因、対処を示します。

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| `coldStart` が `true` のままで、admit が `503` を返し続ける。 | LicOps が Platform からシート数を一度も受け取っていません。 | `GET /api/v1/platform/servers` にライセンスサーバーが表示されることを確認します。`503` が返る場合は、上記リンク先の Router のトラブルシューティングに従ってください。よくある原因は、クライアントの種類が `Router` ではない認証情報です。 |
| それまで動作していた admit が、すべてのリクエストを `StaleSnapshot` で拒否するようになり、`lastReconcileTime` が更新されなくなった。 | Platform との同期が停止しています。Redis が空の状態で再起動されると、Router はバックグラウンドジョブのスケジュールを失い、同期は自動では再開しません。 | Router を再起動し、再発しないように Redis を永続化します。[システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/system-requirements#redis-の要件)を参照してください。 |
| `staleForAdmission` が `true` と `false` の間で切り替わる。 | Platform の応答が遅いか、断続的です。 | LicOps ホストから Platform へのネットワーク経路を確認し、Router のログで同期の失敗を確認します。 |

## LicOps Configuration に Port Mappings が表示されるのはなぜですか

**LicOps Configuration** に **LicOps** と **Rules** ではなく **Port Mappings** が表示される場合は、フェイルオーバー用の Router と連携しています。**LicOps Configuration** は、連携している Router のモードに応じたページを表示します。フェイルオーバー用の Router には **Port Mappings**、LicOps 用の Router には **LicOps** と **Rules** が表示されます。次の表に、症状、原因、対処を示します。

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| LicOps のデプロイなのに、**LicOps Configuration** に **Port Mappings** が表示される。 | Router が `ROUTER_CONFIG_BOOTSTRAP_MODE=loadBalancer` を指定せずに、または `basic` を指定して起動されました。 | [OpenLM LicOps をデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deployment#compose-ファイルを作成する)のとおりに変数を設定します。モードは Router の初回起動時に確定します。専用の空の MongoDB データベースを持つ新しい Router をデプロイし、古い Router を停止してください。 |
| 再読み込みのたびに、ページが **Port Mappings** と **LicOps** の間で切り替わる。 | 2 つの Router（たとえば、フェイルオーバー用の Router と LicOps 用の Router）が同じ OpenLM アカウントに報告しています。**LicOps Configuration** は、最後に報告した Router を対象に動作します。 | OpenLM アカウントごとに Router を 1 つだけ実行します。使用しない Router は停止します。[OpenLM Router の変更、アップグレード、削除](https://www.openlm.com/documentation/ja/cloud/deployment-operations/router/manage/#openlm-router-を削除する)を参照してください。 |
| まだどの Router も自身を報告していないとページに表示される。 | LicOps がまだ Platform と同期していないか、同期する前にページを開きました。ページは自動では更新されません。 | Platform への接続が機能していることを確認してから、ページを再読み込みします。 |
| 各ページに `LicOps License is not available with current openLM License` と表示され、保存が拒否される。 | OpenLM のライセンスに LicOps が含まれていません。 | OpenLM に連絡して、ライセンスを再発行してもらいます。LicOps は既存の構成で動作し続けます。[システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/system-requirements#openlm-ライセンス)を参照してください。 |

## LicOps にプールがないのはなぜですか

`GET /api/v1/stats` が `[]` を返し、すべての admit が拒否されます。次の表に、症状、原因、対処を示します。

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| LicOps を接続してから 1 分以内の時点で、一覧が空になっている。 | LicOps が Platform からライセンスサーバーのデータを受け取っていません。 | [LicOps が OpenLM Platform と同期しないのはなぜですか](#licops-が-openlm-platform-と同期しないのはなぜですか)の手順に従います。 |
| プール、またはプール内の 1 台のサーバーが表示されない。 | Platform がそのライセンスサーバーを監視していません。OpenLM Broker がサーバーにインストールされていないか、**Broker Hub** で承認されていないか、サーバーが **License Servers** で承認されていません。 | [システム要件](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/system-requirements#openlm-platform-の前提条件)の Broker の手順に従ってから、**Live Servers Statistics** でサーバーが **Up** と表示されることを確認します。 |

## リクエストが拒否されるのはなぜですか

拒否の `reason` から調べ始め、[リクエストが拒否された理由を調べる](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/operations#リクエストが拒否された理由を調べる)の説明に従って可用性レポートを確認します。次の表に、症状、原因、対処を示します。

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| プールには空きシートが十分あるように見えるのに、`NoServerAvailable` になる。 | リクエストのベンダーまたはフィーチャーがプールと一致していません。原因はほぼ必ず、大文字・小文字の違いかつづりの誤りです。 | `GET /api/v1/stats` と比較します。Slurm の場合は、ライセンスマップを手で編集せずに再生成します。 |
| Slurm のライセンス名の 1 つが `NoServerAvailable` で拒否されるようになった。ほかの名前は引き続き動作する。 | ライセンスマップの生成後に、Platform でそのライセンスが追加されたか、名前が変更されました。 | [Slurm](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/slurm#ライセンスマップを最新に保つ)の説明に従って、マップを再生成し、定期的な更新をスケジュールします。 |
| 一部のサーバーの `free` にシートが表示されているのに、`NoCapacity` になる。 | **Keep off a server** などのルールが対象のサーバーを絞り込んでいるか、リクエストが、どのサーバー 1 台の空きシートよりも多いシート数を要求しています。 | ルールと、そのプールの `largestAdmittableRequest` を確認します。 |
| `ConstraintBlocked` になる。 | 空きシートのあるすべてのサーバーが、予約によって制限またはブロックされています。 | [スケジュールでシート数を制限する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/reservations)を参照してください。 |
| `PolicyDenied` になる。 | **Deny the request** ルールに一致しました。 | **LicOps Configuration** でルールを確認します。 |
| ルールが効いていないように見える。 | 保存してから 1 分経っていないか、**Target server** がどのサーバーとも一致していないか、条件が大文字・小文字の異なる名前を比較しています。 | 1 分待ってから、`GET /api/v1/rules/router-admission` を確認します。対象はピッカーで選択し、名前は `GET /api/v1/stats` からコピーします。 |
| 時間帯のルールや予約期間が、数時間早く、または遅く始まる。 | LicOps は UTC で動作しています。 | `routerapi` コンテナーに `TZ` を設定します。[スケジュールをタイムゾーンに合わせる](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/reservations#スケジュールをタイムゾーンに合わせる)を参照してください。 |

## シートが返却されないのはなぜですか

`GET /api/v1/stats` のプールの `reserved` の数が増え続け、実行中のジョブは少ないにもかかわらず、リクエストが `NoCapacity` で拒否されるようになります。次の表に、原因と対処を示します。

| 原因 | 対処 |
| --- | --- |
| ジョブが、どのような終わり方をしても必ずシートを解放するようになっていません。 | 必ず実行されるフックまたは `trap` から解放が実行されるようにします。Slurm と LSF の場合は、アダプターの両方のロールがインストールされ、フックが実行されることを確認します。 |
| LSF の `POST_EXEC` がセッション ID を見つけられません。 | `PRE_EXEC` と `POST_EXEC` の両方からアクセスできるディレクトリを `OL_STATE_DIR` に設定します。[IBM Spectrum LSF](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/lsf#問題が発生した場合)を参照してください。 |
| ジョブが admit タイムアウトより長くキューで待機してシートを失い、その後そのまま開始してチェックアウトしています。 | admit タイムアウトを、キューでの通常の待機時間より長くします。[セッションタイムアウトを設定する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deployment#セッションタイムアウトを設定する)を参照してください。 |

解放されなかったシートは、セッションがタイムアウトすると返却されます。すぐに返却するには、[解放されなかったシートを返却する](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/operations#解放されなかったシートを返却する)を参照してください。

## ジョブが LicOps を経由しないのはなぜですか

次の表に、症状、原因、対処を示します。

| 症状 | 原因 | 対処 |
| --- | --- | --- |
| ライセンスを使うジョブが、アダプターのログに admit が記録されないまま開始する。 | ジョブが、（ラッパーではない）本来の `sbatch` で投入されたか、LSF で `-a openlm` を付けずに投入されたか、アダプターのない投入ホストから投入されました。 | [Slurm](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/slurm#ライセンスを使うジョブを投入する)または[IBM Spectrum LSF](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/lsf#ライセンスを使うジョブを投入する)を参照してください。 |
| Kubernetes の Pod が LicOps のコンテナーなしで起動する。 | Namespace のラベル、または `openlm.io/needs-licensing` アノテーションがありません。どちらか一方でも欠けていると、Webhook はエラーを出さずにその Pod をスキップします。 | [Kubernetes ワークロード](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/kubernetes#アドミッション-webhook-で-pod-にライセンスを割り当てる)を参照してください。 |
| オプトインした Namespace で Pod を 1 つも作成できない。 | アドミッション Webhook が利用できず、その失敗ポリシーが `Fail` になっています。 | Webhook を復旧するか、`webhook.failurePolicy=Ignore` を指定して再インストールします。[Kubernetes にデプロイする](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/deploy-kubernetes#アドミッション-webhook-をインストールする)を参照してください。 |
| ジョブは許可されるが、チェックアウトが LicOps の選んだサーバーに向かわない。 | チェックアウトルーティングがない場合、アプリケーションは自身のライセンス設定に従ってチェックアウトします。チェックアウトルーティングがある場合でも、`MLM_LICENSE_FILE` などのベンダー固有の変数が優先されることがあります。 | [LicOps にサーバーも選ばせるかを決める](https://www.openlm.com/documentation/ja/cloud/deployment-operations/licops/integrations/index#licops-にサーバーも選ばせるかを決める)を参照してください。 |
| チェックアウトルーティングを使うと、チェックアウトは LicOps に届くが、対応するジョブと照合されない。 | 計算ノードがアドレス変換を経由して LicOps に接続しているため、チェックアウトが、dispatch で記録された IP アドレスとは異なるアドレスから届いています。 | 計算ノードが LicOps ホストに直接接続できるようにします。 |

## 診断情報を収集する

診断情報を収集するには、次のコマンドを実行します。

```bash
docker compose logs routerapi --tail 200
curl http://localhost:8100/api/v1/status
curl http://localhost:8100/api/v1/stats
curl http://localhost:8100/api/v1/admission-controller/availability
curl http://localhost:8100/api/v1/rules/router-admission
```

Kubernetes では、`kubectl -n <namespace> logs deployment/openlm-routerapi --tail 200` でログを確認し、`kubectl port-forward svc/openlm-router-api 8100:8100` を経由してエンドポイントにアクセスします。スケジューラー側については、投入ホストと、コントローラーまたは実行ホストの `/var/log/openlm/hpc-adapter.log` を含めてください。