NUTマスターからNASがシャットダウンしない

NUTサーバーからのコマンドでNASをシャットダウンさせようとしていますが、さまざまな方法やバリエーションを試しました。サーバー名の変更や、ダミーUPS(qnapups)を追加してadmin/123456ユーザーを設定したり、このブログで紹介されている設定通りに変更したりしました:
https://www.dalbert.net/qnap-nas/
しかし、NASをシャットダウンさせることができません。

現在、上記ブログの各ステップ(NAS側のMONITORコマンドを正しいユーザー名/パスワードに変更し、マスター側にダミーUPS qnapupsを追加)を実行した後、コントロールパネル→外部デバイス→UPSでサーバーIDが正しく認識されており、SSHで upsc myups@<ip> を実行するとUPSデータも取得できます。しかし、何らかの信号を送ってもNASには影響がありません。

マスター側でシャットダウン信号を送る際、

 upsmon -c fsd

を実行すると、他のクライアントはシャットダウンされますが、NASだけはシャットダウンされません。

この扱いにくいNASをシャットダウンさせることができません(以前、純粋なSSHアプローチも試しましたが、さらに悪化しました)。

NASの /etc/config/ups/upsmon.conf は以下の通りです:

RUN_AS_USER admin            
MONITOR qnapnas@<ip> 1 monuser secret slave
MINSUPPLIES 0                
# NASはクライアント(他のデバイスに電源供給していない場合)
SHUTDOWNCMD "/sbin/shutdown -h +0"
FINALDELAY 0     

(他のファイルは未変更です)

ご覧の通り、upsc myups@ip(実UPS)も upsc qnapups@ip(ダミーUPS)も期待通り動作しますが、シャットダウンが実行されません。また、

upscmd -u monuser -p secret qnapups@ip load.off
OK
upscmd -u monuser -p secret qnapups@ip driver.killpower
OK

どちらもNASをシャットダウンしません。

ログもなく、私の理解ではNUTクライアントの完全なバージョンがこのNASには搭載されていないため、期待通りに全てのログファイルが動作しているわけではないようです。

ローカルでシャットダウンテストをデバッグする方法も分からず、upsmon -c fsdはNAS上では動作しません:

[~] # sudo upsmon -c fsd
Network UPS Tools upsmon 2.7.4
kill: No such process

どなたか助けていただけるとありがたいです!

モデル: TS-832PX
ソフトウェア: QTS 5.0.1 2376

弊社のUIを使ってNUT Slaveの設定をお試しいただけますか?それとも、UIから直接設定できない特別な理由がありますか?

コマンド使用時の問題については、社内チームに分析を依頼します。ご報告ありがとうございます。

ついに、BLステータスに従うようになり、UIで定義したタイマーが開始されるようになりました。以前は動作していませんでした(適用ボタンのほかに再起動が必要だったのかもしれません)。
しかし、私は特定のタイミングでFSD(ファイナルシャットダウン)をトリガーしたいので、バッテリーイベントのタイマーは使いたくありません。UIでタイマーを100分に設定して、邪魔にならないようにしています。
マスターからupsmon -fsdに従ってほしいのですが、現在はそうなっていません。
dummy-upsで0分タイマーを設定すればできるかもしれませんが、UIではそれが許可されません。

何か進展はありますか?

以前、旧フォーラムにて修正方法をドキュメント化したことがありましたが、今はもうそのフォーラムはありません。

最近UPSをUnifi UPS 2Uに変更し、このモデルはNUT Serverをサポートしており、UPSName・ユーザー名・パスワードの設定が可能です。

claude desktop(クラウドデスクトップ)を使って再び動作させることができました。これがあなたの助けになれば幸いです。

QNAPをNUT(Network UPS Tools)クライアントとして修正 — GUI「Network UPS slave」は正常に動作しない

セットアップ

  • 別デバイスで稼働しているNUTサーバー(今回はUniFi UPSがNUTサーバーとして動作)、<NUT_SERVER_IP>:3493で接続可能。
  • QNAP NAS(QTS 5.2.9)がクライアント/スレーブとしてそのUPSの監視を必要としており、電源イベントに応答できるようにする。

問題点

QNAPのGUI機能 — コントロールパネル → システム → 電源 → UPS →「Network UPS slave」 — はサーバーのIPアドレスしか入力を求めません。ユーザー名やパスワードの項目はありません

本来のNUTのMONITOR接続(認証されたクライアントとして登録し、適切なシャットダウン連携を行うための接続)には、サーバー側のupsd.usersで設定された認証情報が必要です。しかしこれがGUIにより設定されないため、QNAPのGUIによるプロセス(upsutil)では完全な認証ができません。その結果:

  • NASがNUTサーバーの接続クライアント一覧に表示されない
  • GUI上のUPS情報フィールドが空白(AC電源状態、バッテリー容量、モデル — すべて--のまま)、UPSは稼働していても情報が表示されない。

手動で読み取り専用クエリを実行すると正常動作:

upsc <ups_name>@<NUT_SERVER_IP>

これで実際のバッテリー残量、負荷、ステータスなど、ライブデータは取得可能 — サーバーに到達できUPS名も正しい。しかしこれは認証不要の「読み取り」のみで、監視クライアント接続ではない。つまり、監視用デーモンが動作しているかはわからない。

重要な発見:ps | grep -i upsで確認するとupsutilしか動作していない — NAS上で本来必要なupsmon(NUTの監視デーモン)がまったく起動していない。GUIの「Network UPS slave」オプションはこれを起動しない。

修正方法

1. 本来のupsmon設定ファイルを直接編集

QNAPは標準のNUT upsmon.confを搭載していますが、GUIからはMONITOR行に認証情報が設定されません。直接編集(SSHやSFTPで)します:

/etc/config/ups/upsmon.conf

サーバー側のNUT認証情報に従ってMONITOR行を追加/修正してください:

MONITOR <ups_name>@<NUT_SERVER_IP>:3493 1 <monitor_username> <monitor_password> slave

ヒント:正しい<ups_name>はNUTサーバー内部のデバイス名で、「ups」とは限りません。

upsc -l <NUT_SERVER_IP>

2. 監視デーモンを起動

QNAPのupsmonバイナリは標準NUTとは違い-c <path>を受け付けません(このフラグはfsd/reload/stopなど別用途)。設定ファイルは上記/etc/config/ups/upsmon.confから自動的に読み込むため内容を修正したら、次を実行:

/usr/sbin/upsmon

デーモンが動作中か確認(親プロセスと子プロセスの両方が表示されるはず):

ps | grep -i upsmon

起動するとNASは即座にNUTサーバーのクライアントリストに正しく表示され、認証も完了。

3. 永続化(crontabによる監視)

QNAPのGUIは手動でプロセスが起動したことを認識できないため再起動やGUI操作によるプロセス終了が発生する。QNAPのautorun.shはコントロールパネル → ハードウェア → 一般で有効化が必要かつMalware Removerアプリのスキャンで無効化されることもあるので、crontabによる監視がより信頼できます:

*/5 * * * * pgrep -x upsmon >/dev/null || /usr/sbin/upsmon

5分ごとにupsmonが動作しているかチェックし、動作していなければ自動再起動 — 再起動やクラッシュ、GUIによる停止にも対応。

QNAPで重要: /etc/config/crontabを(例えばSFTPでNotepad++などから)直接編集しても、crond.sh restartだけでは反映されません。実際のcrontabへファイルを読み込み直す必要があります:

crontab /etc/config/crontab && /etc/init.d/crond.sh restart

反映確認:

crontab -l

(Windowsから編集する場合は改行コードをUnix/LFにしておくと、cronが行を無視する問題の回避になります。)

結果

  • upsmonが継続稼働し、認証も完了。NUTサーバーのクライアントリストにも表示される。
  • upsc <ups_name>@<NUT_SERVER_IP>によるUPSライブデータの確認が可能。
  • cronの監視により再起動やGUI解除でも自動で再起動され、QNAPの脆弱なautorun.shに依存しない。

根本原因まとめ

QNAPの「Network UPS slave」GUI機能は簡易的で認証を行わないラッパー(upsutil)であり、標準NUTupsmonデーモンとは異なり、認証付きクライアント監視を行えません。QNAPのUPSステータスページが空白表示でNASがNUTサーバーのクライアントリストに現れない場合は、upsmonが実際に稼働しているか(ps | grep upsmon)の確認を — 多くの場合、GUIの表示に関わらず起動していません。

:warning: 注意: これはQNAP独自のUPS管理(upsutil やGUIの「Network UPS slave」オプション)を迂回し、標準のNUT upsmon デーモンを手動で実行し、カスタムの SHUTDOWNCMD を設定する方法です。QNAPの公式サポート対象ではありません。実運用前に必ず自身の環境でテストしてください。これらの手順により生じるデータ損失、シャットダウン失敗、その他の問題について、私は一切責任を負いません。

QNAP + NUT: QNAPのupsutilではなくupsmonを使う場合のSHUTDOWNCMD修正方法

QNAPの独自「Network UPS slave」オプション(こちらはupsutilツールを使用し、認証付きNUT接続には対応していません)を迂回して、標準のNUT upsmon デーモンを直接動かしている場合、もうひとつ修正が必要です。upsmon.confのデフォルト SHUTDOWNCMDQNAPでは動作せず、実際の停電時にも静かに失敗します

問題点

QNAPはupsmon.confを、NUT上流のデフォルトテンプレートそのままで出荷しています:

SHUTDOWNCMD "/sbin/shutdown -h +0"

これはNUTのソースパッケージの汎用例であり、全てのLinuxディストリで同じデフォルトになっています。QNAPはこのファイルを自社OS用に調整せず、そのまま含めています。なぜなら、公式のサポートパスは最初からupsmonを使う想定がなく、upsutilベースだからです(認証付きNUTサーバーでupsutilがうまく動作しない理由については別投稿を参照)。

結果として、QNAP(QTS)には /sbin/shutdown が存在しません。以下で確認できます:

which shutdown
ls -la /sbin/shutdown

もしupsmonが、UPSがバッテリーで動作中・危機的状況になった際、緊急シャットダウンを実行する必要がある場合、このコマンドは単純にエラーとなり — upsmonの視点からは黙って失敗 — システムは死にかけのUPS上で停止せず稼働し続けます。

upsutilにはなぜこの問題がないか

upsutil(QNAP独自ツール)は、そもそもSHUTDOWNCMDを通過しません。シャットダウンやアンマウントのロジックが内部でハードコーディングされており、QNAP正規の電源断ルートを直接呼び出しているものと思われます。upsmon/upsmon.conf とは完全に分離されたコードパスです。SHUTDOWNCMD 行が考慮されるのは、upsmonを自分で動かしている時だけです。

修正方法

QNAPの本来の電源断エントリポイントは:

/sbin/poweroff

これはQNAP自身の /etc/init.d/poweroff スクリプトが内部で呼び出している実バイナリ(緊急UPSシャットダウンの場合、独自のスケジューリングやボリュームチェックは不要なので即時実行向き)です。

upsmon.conf を以下のように修正してください:

SHUTDOWNCMD "/sbin/poweroff"

その後、upsmon を再起動して設定を反映させます:

pkill upsmon
/usr/sbin/upsmon

まとめ

QNAP NASでupsmonを設定する場合(GUIの「Network UPS slave」オプションが認証付きNUTサーバーに非対応だから)、upsmon.confにあるデフォルトのSHUTDOWNCMDは信用しないでください — これは上流NUTの汎用テンプレートでQNAP向けに調整されておらず、参照されたバイナリがQTSには存在しません。実運用前に必ず /sbin/poweroff に変更しましょう。

回避策を避けるために、もっと汎用的な実装(またはサポート)を製品の改善としてリクエストしたほうがいいかもしれませんね。良いユースケースだと思います。

Qnapが最初からNUT(Network UPS Tools)をサポートしてるところを想像してみて…そんなことあると思う人いる?:rofl: