SUSE Linux Enterprise で Zypper ロックを安全に解除する

SUSE Linux Enterprise が Zypper が他のプロセスによってロックされていると報告した場合、まずアクティブなソフトウェア更新、YaST パッケージ操作、または自動メンテナンス ジョブがすべて完了するまで待ちます。停止する前に、どのパッケージ管理プロセスがその作業を所有しているかを確認してください。パッケージ操作が実行されておらず、ロックが残っている場合は、ロック ファイルをむやみに削除せずに古い状態を調査し、その後 Zypper を再試行してください。パッケージ ロックがzypper addlock別の問題として作成されている場合は、別の修正が必要です。

「別のプロセスによってロックされている」とはどういう意味ですか？

Zypperおよび基盤となるパッケージ管理ツールは、パッケージトランザクションが重複して変更されるのを防ぎます。更新、パッチ適用、インストール、YaSTソフトウェアタスク、またはスケジュールされたアップデートは、一時的に2回目のトランザクションを阻止することができます。ロックは調整メカニズムであり、RPMまたはZypperがパッケージを変更している間にロックを解除すると、パッケージデータベースまたはシステムが矛盾した状態になる可能性があります。

検証済みの区別：プロセスロックは同時パッケージ操作を防止します。パッケージロックは、指定されたパッケージがインストール、アップグレード、または削除のために選択されないようにします。SUSE のドキュメントでは、パッケージロックは別の機能として説明されています。SUSEの RPM パッケージング ガイドでは、Zypper パッケージロックについて説明しています。エラーで別のプロセスが挙げられている場合、またはパッケージマネージャがビジー状態であると示されている場合は、以下のプロセスチェックから始めてください。特定のパッケージがロックされているか除外されていると示されている場合は、sudo zypper locks代わりにリストされているパッケージルールを実行して確認してください。

1. パッケージ操作がまだ実行中かどうかを確認します。

アップデート、インストール、またはリポジトリの更新が開始されたばかりの場合は、数分お待ちください。サーバーの場合は、まず管理者またはメンテナンス自動化担当者に確認してください。バックグラウンドで実行されているパッチジョブには、目に見える端末がない場合があります。

ps -eo pid,ppid,etime,stat,cmd | grep -E '[z]ypper|[r]pm|packagekit|YaST|yast'

実際の Zypper、RPM、YaST、または PackageKit タスクを探し、その PID、経過時間、およびコマンドをメモしてください。grep 式は、Zypper と RPM の検索コマンド自体に一致しないようにします。プロセス一覧はスナップショットなので、結果が不明瞭な場合は、少し待ってから再度実行してください。以下のサンプルは、実際のマシンからのレポートではなく、ターミナル画面の例です。

まだ確定していない点：プロセスが表示されているからといって、それが停止しているとは限らない。パッケージトランザクションはメタデータをダウンロード中であったり、ストレージやリポジトリを待機中である可能性がある。コマンドが静止しているからといって、プロセスを強制終了してはいけない。処理が進行している場合は、完了するまで待ってから、元の Zypper コマンドを再実行してください。

2. ソフトウェア管理サービスとメンテナンスジョブを確認する

デスクトップ環境ではPackageKitが使用される場合があり、管理対象サーバーではsystemdタイマーまたはSUSE Managerを介してスケジュールされたアップデートが実行される場合があります。ホスト上に存在するサービスのみを確認してください。

systemctl status packagekit
systemctl list-timers --all

PackageKitが存在しない場合、systemdはユニットが見つからないと報告しますが、これはZypperが壊れているという意味ではありません。Zypperがアクティブな場合は、停止を検討する前に、最近のジャーナルエントリを調べて、インストールや更新が進行中でないことを確認してください。

sudo journalctl -u packagekit --since "30 minutes ago"

確認済みの PackageKit 操作が完了しても、そのサービスがアクティブなままで Zypper をブロックしている場合は、更新を管理している担当者または自動化ツールと連携してください。停止が適切なホストでは、 を使用しsudo systemctl stop packagekit、 で確認してくださいsystemctl status packagekit。一般的な解決策として、サービスを無効にしたり、無関係な更新タイマーを停止したりしないでください。名前と更新スケジュールは、システムにインストールされているコンポーネントと管理ポリシーによって異なります。

3. 所有者がアクティブでない場合は、古いロックを安全に調査します。

古いロックは、セッションの中断、再起動、または管理タスクの失敗後に発生する可能性がありますが、その存在だけでは原因を特定できません。SUSE のユーザー ドキュメントには、すべての SLES リリースと構成に対してロック ファイルを削除するための統一された手順は記載されていません。rm推測されたパスに対してなどのコマンドを使用しないでください。また、不明な PID に対しては使用しないでくださいkill -9。ロック ファイルはトランザクションがアクティブな間に再作成または置き換えられる可能性があり、ロック ファイルを削除してもトランザクションを所有するプロセスは停止しません。

プロセス一覧を再確認し、関連するサービスログを調べ、パッケージ操作が進行中でないことを確認してください。古い PID ファイルまたはロック パスが見つかった場合は、所有者を確認し、変更する前に、ご使用の SLES サービス パックまたはサポート ガイダンスに記載されている手順を確認してください。本番システムの場合は、正確なエラーとログを取得し、組織の SUSE サポート プロセスに従ってください。エラー テキスト、SLES サービス パック、インストールされているデスクトップ ツール、管理エージェントなど、ローカルの詳細が重要になります。これらの要素によって、適切な復旧アクションが変わる可能性があります。

4. Zypperを再度実行し、トランザクションを確認してください。

競合操作が完了したら、リポジトリのメタデータを更新します。

sudo zypper refresh

更新が正常に完了すると、Zypperがリポジトリにアクセスできるようになり、プロセスロックがコマンドの実行を妨げなくなったことが確認できます。当初のタスクがシステムのパッチ適用だった場合は、変更を適用する前に提案された変更内容をプレビューしてください。

sudo zypper patch --dry-run

出力のパッケージとアクションを確認してください。ドライランは計画チェックであり、リストされているアップデートはインストールされません。提案が予定されており、メンテナンス期間が許す場合は、 を実行してくださいsudo zypper patch。SUSE の SLES 15 SP7 ドキュメントでは、ソフトウェアのインストールと削除を含むコマンドラインソフトウェア管理について説明しています。コマンドの動作と使用可能なオプションはリリースによって異なる場合があります。SLES 15 SP7 ソフトウェア管理ドキュメントとSUSE の Zypper リファレンスを参照してください。

避けるべき一般的な思い込み

• 「ロックは常に古い状態です。」このメッセージだけでは確認できません。実際のアップデートに関連している可能性もあります。まずはアクティブなプロセスとログを確認してください。
• 「パッケージロックとプロセスロックは同じものです。」これらは別々の制御手段です。zypper locks指定されたパッケージを明示的にロックする場合に使用してください。実行中のトランザクションをクリアするためにパッケージルールを削除しないでください。
• 「ロックファイルを削除しても、所有者は修正されます。」これは、アクティブなプロセスを終了させたり、トランザクションを安全に完了させたりするものではありません。まず所有者を特定し、古い状態についてはリリース固有のガイダンスに従ってください。
• 「サーバーの再起動が通常の解決策です。」再起動はパッケージの変更を中断させる可能性があり、エラーが発生したという理由だけで行うべきではありません。保守手順やサポートガイドラインで指示されている場合にのみ実行してください。

修正を確認してください

sudo zypper refreshロックエラーが発生しずに処理が完了し、目的のコマンドが実行可能になった時点で問題は解決します。sudo zypper patch --dry-runパッチを適用する前に、提案されている動作を検査して確認してください。ロックが再び発生した場合は、正確なエラー、プロセス一覧、関連するサービスの状態、最近のジャーナル出力、およびSLESリリースを記録し、ロック状態を繰り返し削除するのではなく、ロックを再取得しているプロセスまたは管理ツールを調査してください。