不適切なシャットダウン
不適切なシャットダウンは、Unraid が array がシステムの電源が切れる前に正しく停止されなかったことを検出したときに発生します。この状況では、データの整合性を確保するため、次回の起動時に自動的に parity check が実行される場合があります。
いくつかの予防策を講じることで、不適切なシャットダウンを回避または特定しやすくなります:
- UPS を使用する: サーバーを無停電電源装置（UPS）に接続し、バッテリー残量が少なくなったときに制御されたシャットダウンを開始するよう設定します。
- 正常なシャットダウンを試みる: サーバーが応答しない場合は、電源ボタンを短く押して安全なシャットダウンを開始します。ボタンを押し続けないでください。強制的に電源が切れ、不適切なシャットダウンにつながります。
- 永続ログを有効にする: Settings → Syslog Server に移動して、再起動後も保持されるログを有効にします。詳細は 永続ログ (Syslog server) を参照してください。
- サポート用の診断を添付する: 不適切なシャットダウンが発生した場合、Unraid はフラッシュデバイス上の
/log/diagnostics.zipに診断情報を保存しようとします。サポートを求めるフォーラム投稿には、このファイルを添付してください。
適切に構成された UPS は、停電による不適切なシャットダウンに対する最善の防御策です。
- UPS を USB で Unraid サーバーに接続します。
- Settings → UPS Settings で UPS support を有効にします。
- シャットダウンタイムアウトの設定: バッテリー残量が少なくなる前に、UPS が制御されたシャットダウンを開始するように設定します。"Battery runtime left" または "Battery charge level" のしきい値を調整し、Unraid が array を停止する ための十分な時間を確保して、安全に電源を切れるようにします。
- 設定をテストする: 停電をシミュレートして、UPS と Unraid が正しく応答することを確認します。
より高度な UPS モデルや未対応のハードウェアとの互換性を広げるには、NUT プラグイン を検討してください。
不適切なシャットダウンを引き起こすイベント
不適切なシャットダウンの主な原因を理解することで、それらを防ぎやすくなります。以下のセクションでは、最も一般的なケースとその解決策を説明します。
予期しない電源断
電源の中断は、正常でないシャットダウンの主な原因の一つです。バッテリーが切れる前に Unraid を自動的にシャットダウンできるよう、適切に設定された UPS でシステムを保護してください。
Unraid は、apcupsd Protocol プロトコルを使用するほとんどの UPS ユニットをサポートしています（APC と CyberPower は通常互換性があります）。お使いの UPS がサポートされていない場合は、Community Applications の Network UPS Tools（NUT）プラグインを検討してください。
フラッシュドライブの障害
array の状態は USB フラッシュデバイスに保存されています。フラッシュドライブが利用できなくなったり読み取り専用になったりすると、array が正常に停止していても、Unraid はシャットダウン状態を更新できません。その結果、次回の起動時に不完全なシャットダウンとして検出されます。
ターミナルセッションを開いたままにする
Unraid はシャットダウン中に、開いているすべてのターミナルまたは SSH セッションが終了するのを待機します。これらのセッションがアクティブなままでシャットダウンタイマーが切れると、強制シャットダウンが実行されます。
Dynamix Stop Shell プラグインは、残っている bash または SSH セッションを自動的に終了でき、適切なシャットダウンを確実にするのに役立ちます。ただし、array への書き込み操作が進行中の場合は注意してください。
シャットダウンタイムアウトの設定
シャットダウンのタイムアウトを適切に設定することは、Unraid サーバーがすべてのサービスを正常に停止できるようにするうえで不可欠です。これにより、特に停電やメンテナンス時の不完全なシャットダウンを防げます。最も重要なのは、VMs を停止ではなく休止状態に設定することです。この方法により、タイムアウト関連の多くの問題を解消できます。
VM の休止状態の設定
最も信頼性が高く、最も高速にシャットダウンするには、VMs を停止ではなく休止状態に設定してください。これは特に Windows VMs で重要ですが、すべての VM タイプにメリットがあります。
休止状態を使用することを推奨する理由は次のとおりです:
- VM の状態を即座に保存 - ゲスト OS のシャットダウンを待つ必要がありません。
- データ損失を防止 - 更新や未保存の作業を中断するリスクがありません。
- タイムアウトの問題を回避 - 休止状態はほぼ瞬時に完了します。
- 復帰が高速 - VMs は中断した時点からそのまま再開します。
シャットダウンが問題になるのは次のためです:
- Windows ではダイアログボックス（"このドキュメントを保存しますか?"）が表示され、シャットダウンが無期限に停止することがあります。
- Windows 更新は、シャットダウン中に 10 分以上かかることがあります。
- タイムアウトが切れると、Unraid は VM を強制終了し、進行中の Windows 更新、未保存のドキュメント、アプリケーションデータ、およびゲスト OS のファイルシステムを破損する可能性があります。
重要な要件: 休止状態を正しく機能させるには、VM に QEMU Guest Agent がインストールされていることを確認してください。
VM の休止状態を有効にするには:
- Windows VM
- Linux VM
- アプライアンス VM
-
QEMU Guest Agent をダウンロード:
- VirtIO ドライバーのダウンロードページ に移動します。
- 最新の
virtio-win.isoファイルをダウンロードします。
-
Windows VM にインストール:
virtio-win.isoを VM にマウントします。- マウントした ISO からインストーラーを実行します。
- VirtIO ドライバーと QEMU Guest Agent の両方をインストールします。
- VM を再起動します。
-
Unraid で設定:
- VMs タブで VM の設定に移動します。
- Shutdown Action を Hibernate に設定します。
- Apply をクリックします。
- QEMU Guest Agent をインストール:
# Ubuntu/Debian
sudo apt install qemu-guest-agent
# CentOS/RHEL/Fedora
sudo yum install qemu-guest-agent
# or
sudo dnf install qemu-guest-agent
-
サービスを有効にする:
sudo systemctl enable qemu-guest-agent
sudo systemctl start qemu-guest-agent -
Unraid で設定:
- VM の設定で Shutdown Action を Hibernate に設定します。
Home Assistant のような一部の VMs では、追加ソフトウェアをインストールできません。この場合は次のとおりです:
- Shutdown Action は Shutdown のままにします。
- より長いタイムアウト値を使用します（以下のタイムアウト推奨を参照）。
- 更新中にこれらの VMs を強制終了するリスクを考慮してください。
アプライアンス VMs は特定のソフトウェアを実行するよう設計されており、QEMU Guest Agent のような追加パッケージをインストールできないことがよくあります。つまり、休止状態は利用できないため、適切なタイムアウト設定に頼る必要があります。
休止状態が機能するか確認するには、VM を起動していくつかのアプリケーションを開きます。次に Unraid から停止します。再度起動すると、すべてのアプリケーションが開いたままの状態で再開されるはずです。
QEMU Guest Agent がインストールされていない場合、休止状態が正しく動作しないことがあります。その場合、VM はシャットダウンモードに戻り、タイムアウトの全時間を消費します。
タイムアウトの設定
このセクションでは、さまざまなシステムやプロセスのタイムアウトの設定方法を説明します。この情報は、VMs と Docker コンテナがデータ損失なく適切にシャットダウンするために重要です。
| 設定 | デフォルト | 増やすタイミング | どこで設定するか |
|---|---|---|---|
| VM シャットダウンタイムアウト | 60秒 | 休止状態を使用せず、VM がクラッシュする場合は 300 秒 | Settings → VM Manager → VM Shutdown (Advanced) |
| Docker コンテナ停止タイムアウト | 10秒 | 停止時にいずれかのコンテナがクラッシュする場合は 30 秒 | Settings → Docker (Advanced) |
| 一般的なシャットダウンタイムアウト | 90秒 | 不完全なシャットダウンが発生する場合は 180 秒、VM がある場合は 300 秒以上 | Settings → Disk Settings → Shutdown time-out |
不完全なシャットダウンが発生している場合や、停止時にクラッシュするコンテナがある場合は、一般的なシャットダウンタイムアウトを 180 秒 に増やすことを検討してください（複数の VMs がある場合は 300 秒以上）。これにより、サービスが適切に停止するための時間をより多く確保できます。
シャットダウンの順序
シャットダウン時、処理は次の順序で行われます:
-
VM のシャットダウン: これは 3 つの段階で構成され、それぞれの段階で VM のタイムアウト全体を使い切る可能性があります:
各ステージのすべての VMs は同時に処理されるため、合計のシャットダウン時間は VM タイムアウト × 3 として計算できます。
-
Docker コンテナは同時に停止します（合計時間 = Docker タイムアウト）。
-
その他のサービスには、LXC コンテナやサードパーティのプラグインなどがあり、通常は数秒で完了します。
-
アレイのシャットダウン: ドライブのマウント解除とデータ同期が必要で、通常は 15〜30 秒かかります。
式: 一般的なシャットダウンタイムアウトは次より大きくする必要があります:
(VM timeout × 3) + (Docker timeout) + (Other services) + 15-30 seconds
例: 式に従うと、(300 × 3) + 30 + 10 + 30 = 970 seconds (over 16 minutes) のようになります。
推奨: 最低でも 180 秒（3 分）、複数の VMs や複雑なコンテナがある場合は 300 秒以上（5 分以上） を推奨します。
すべての VMs を停止ではなく休止状態に設定している場合、休止はほぼ即時のため VM タイムアウトの重要性は低くなります。休止状態をサポートしない VMs のための予備として、より短い VM タイムアウト（たとえば 60〜120 秒）を使用できます。
詳細な設定ガイド
このセクションでは、さまざまなシステムコンポーネントのタイムアウト設定について詳しく説明します。各タイムアウト設定は連携して、データ損失なくサーバーを適切にシャットダウンするために機能します。
VM タイムアウト
Settings → VM Manager → VM Shutdown で VM のシャットダウンタイムアウトを設定します（Advanced 表示を有効にします）。
仕組み:
- VMs は 3 つのシャットダウン段階を経て、それぞれで VM のタイムアウト全体を消費します
- 各ステージのすべての VMs は同時に処理されます
- VM の合計シャットダウン時間 = VM タイムアウト × 3
よくある問題:
- Windows 更新の中断: タイムアウトが切れると、シャットダウン中の更新が破損する可能性があります。
- 未保存の作業: ドキュメントの保存を求めるダイアログボックスが、シャットダウンを無期限に停止させることがあります。
- 休止状態の失敗: QEMU Guest Agent がない VMs は休止に失敗し、タイムアウト全体を使用する場合があります。
- 主な推奨事項: VMs を停止ではなく休止状態に設定します（QEMU Guest Agent が必要です）。
- VM がシャットダウン中にクラッシュする場合: Windows VMs のタイムアウトを 300 秒（5 分） に増やします。
- Windows 更新: Windows はシャットダウン中ではなく起動時に更新をインストールするように設定します。
- 設定をテストする: VMs を手動で停止し、タイムアウト期間内に停止または休止することを確認します。
休止状態と QEMU Guest Agent がない場合、Windows VMs に真に安全なタイムアウトはありません。ダイアログボックスや進行中の更新インストールにより、どのタイムアウトでも不十分になり、強制シャットダウンやデータ破損のリスクにつながる可能性があります。
Docker のタイムアウト
Settings → Docker で Docker コンテナの停止タイムアウトを設定します（Advanced 表示を有効にします）。
仕組み:
- コンテナは並列で停止するため、合計時間は Docker の停止タイムアウトに等しくなります。
- ほとんどのコンテナは 10 秒以内に停止しますが、さらに時間が必要なものもあります。
- 大きなデータベースや進行中の操作を伴う複雑なコンテナでは、追加の時間が必要になる場合があります。
- タイマーが切れると、コンテナは強制停止されます。
- デフォルトの 10 秒 は、ほとんどのコンテナに適しています。
- 停止時にコンテナがクラッシュする場合: タイムアウトを 30 秒 に増やします。
- シャットダウン中にコンテナを監視し、継続的により長い時間が必要なものを特定します。
一般的なタイムアウト
一般的なシャットダウンタイムアウトは Settings → Disk Settings → Shutdown time-out で設定します。
UPS の考慮事項（最重要要素）:
- バッテリーが切れる前に完全なシャットダウン手順を完了できるだけの稼働時間を UPS が提供できる必要があります。
- 手動シャットダウン では、開始時刻を自分で制御できるため、より長いタイムアウトを設定できます。
- 停電時のシャットダウン では、タイムアウトは UPS のバッテリー寿命によって制限されます。
- 停電を模擬して UPS をテスト し、サーバーが余裕を持って正常にシャットダウンすることを確認します。
サードパーティサービス
LXC コンテナ: LXC プラグインには、コンテナを停止するための独自のタイムアウト設定があります。Docker コンテナと同様に、LXC コンテナは通常数秒で停止しますが、さらに時間が必要な場合があります。コンテナ停止タイムアウトについては LXC プラグインの設定を確認し、このタイムアウトを一般的なシャットダウンタイムアウトの計算に含めてください。
その他のサービス: 一部のプラグインやカスタムサービスには独自のシャットダウン手順がある場合があります。具体的なタイムアウト設定についてはプラグインのドキュメントを参照し、計算に組み込んでください。
サードパーティサービスを含めた更新後の式:
(VM timeout × 3) + (Docker timeout) + (LXC/other timeouts) + 15-30 seconds
Dynamix Stop Shell プラグイン: SSH やターミナルセッションを頻繁に使う場合、開いたままのセッションが不完全なシャットダウンの原因になることがあります。Unraid はそれらが閉じるのを待ってから処理を進めるためです。
Dynamix Stop Shell プラグインは、アレイ停止時に残っている bash または SSH セッションを自動的に閉じることで、時間どおりのシャットダウンを支援します。
Community Applications（"Dynamix Stop Shell" で検索） からインストールできます。
- ターミナルセッションを定期的に開いたままにする場合。
- 忘れられた SSH セッションによってシャットダウンが遅れないようにするため。
- シャットダウン時に自動でクリーンアップするため。
- ターミナルセッションでスクリプトや処理を実行している場合は注意してください。
- シャットダウン前に重要な書き込み操作が進行中でないことを確認してください。
- このプラグインはセッションを強制的に閉じるため、作業が中断される可能性があります。