0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ynott(Tetsrou YNO)in株式会社スタイルズ

NVIDIA BCM 11でNVLinkSDNPartitionz欠落によりcmdが大量エラーになった原因と対処

0
Last updated at Posted at 2026-03-28

毎度、ググっても出てこない小ネタを取り扱っております。
本記事は個人的な見解であり、筆者の所属するいかなる団体にも関係ございません。

本ブログは、問題解決の為にGPT-5.4と会話した内容を元にGPT-5.4で作成しました。

0. 環境

本事象を確認した環境を整理する。

0-1. ソフトウェア構成

  • BCM: 11.0
    • cmdaemon 11.0-164369-cm11.0-01b8e576a4
    • bcm-post-install 11.0-100222-cm11.0-b7bdaa232a
    • bcm-superpod-network 11.0-100315-cm11.0-99c7d7a5c9`
  • OS: Ubuntu 24.04.4 LTS (Noble Numbat)
  • Kernel: 6.8.0-90-generic
  • Database: MySQL 8.0.45
  • kubectl client: v1.33.7 (linux/amd64)

0-2. 事象発生時の状態

障害発生時点では cmd.service 自体は起動していた。
cmdaemon DB への書き込みが継続的に失敗していた。
それにより以下のログが大量に出力されてDiskが枯渇した。

1. BCM 11でNVLinkSDNPartitionzテーブル欠落によりcmdが大量エラーになった話

BCM 11 の head nodeで、cmd.serviceは起動していて、内部ではDB書き込みエラーが大量発生していた。症状は次の2点だった。

  • Table 'cmdaemon.NVLinkSDNPartitionz' doesn't exist (1146)
  • MysqlEngine::store(DataLink.add/remove), too many: ... > 4096

この時点で分かるのは、cmd が NVLinkSDNPartitionz へ書き込もうとしている一方、そのテーブルが DB に存在しなかった。too manyは、その失敗がキューに蓄積されていました。

2. 初期観察

最初に確認したログでは、DataLink.add / DataLink.removeが1146で継続的に失敗していました。しかも件数は527061 > 4096や156582 > 4096のように上限を大幅に超えていました。これは一過性の警告ではなく、継続的な保存失敗です。

2-1. 最初の仮説

初期段階では、原因を次の2つに絞りました。

  1. cmdaemonDBのスキーマ不足
  2. BCM / cmdaemonパッケージのupgrade未完了

理由は単純です。存在しないテーブル名に対してcmdが書き込みを試みていたためです。これは、アプリケーションコードとDBスキーマの不一致を示す典型的な症状です。

2-2. まずdpkgの不整合を解消しました

dpkg --auditを確認すると、cmdaemonを含む多数のパッケージが未設定または半設定状態でした。cmdaemon自体もhalf configuredでした。つまり、upgrade処理がOSレベルで完了していませんでした。

そこで、まず次を実行しました。

dpkg --configure -a
apt-get -f install

この結果、cmdaemonを含む関連パッケージのconfigureが完了し、apt-get -f installもエラーなく終了しました。

2-3. dpkg修復後も本件は未解決でした

dpkg修復後、cmdaemon* / bcm*パッケージはすべてiiになりました。ここでOSパッケージ管理上の不整合は解消しています。

しかし、SHOW TABLES LIKE 'NVLinkSDNPartitionz'は空のままでした。また、cmd.serviceはactiveですが、ログには引き続き1146とtoo manyが出ていました。

この結果から、原因はdpkgではなくDB migration未反映に絞り込めました。

2-4. ここまでの証拠

この時点での証拠は明確でした。

  • パッケージ状態はii
  • NVLinkSDNPartitionzは存在しない
  • cmdはそのテーブルへの書き込みで失敗している

つまり、「パッケージは入っているが、必要なDB upgradeが完了していない」という構図です。

3. cmdaemon.postinstを確認しました

次にcmdaemon.postinstを確認しました。ここで重要だったのは、DB upgradeが無条件ではなく、cmdaemonctl upgradeに委譲されていた点です。

if [ -n "$2" ] && [ -z "$CMDAEMON_DB_NOT_INITIALIZED" ]; then
    /cm/local/apps/cmd/sbin/cmdaemonctl upgrade
    systemctl start cmd
    ...
fi

ここから分かるのは、DB upgradeはpostinstの中で自動実行される場合もありますが、条件次第では十分に反映されない可能性がある、ということです。

3-1. DB側の状態も確認しました

SHOW TABLESを確認すると、NVDomainInfoやPartitionsなど、NV / Partition系の関連テーブルは存在していました。一方で、NVLinkSDNPartitionzだけが欠落していました。

これはDB全体の破損ではなく、特定migrationの未反映を示す証拠です。

3-2. この時点の結論

ここまでの観察から、結論は次の通りでした。

  • dpkgの不整合は存在したが、それ自体は解消済み
  • それでもNVLinkSDNPartitionzは作成されていない
  • よって、本件の直接原因はcmdaemonのDB migration不足である

4. cmdを停止してcmdaemonctl upgradeを手動実行しました

次の方針は単純です。cmdを停止した上でcmdaemonctl upgradeを明示的に実行することにしました。

まずcmdaemonctl --helpを確認すると、upgradeサブコマンドが存在していました。

cmdaemonctl [OPTIONS...] COMMAND ...

Commands:
  debugon
  debugoff
  full-status
  upgrade
  logconf

これは、DB upgradeを手動で実行する手段が公式に用意されていることを意味します。

4-1. cmdは正常停止できませんでした

systemctl stop cmdを実行しましたが、cmd.serviceはすぐには止まらず、deactivating (stop)のまま残りました。ログにはMysqlEngine::save, stopped before adding: 13が繰り返し出ていました。

これは、停止要求は受けているものの、内部の保存処理が詰まっている状態と解釈できます。最終的にsystemdがSIGKILLを送り、safe_cmdとcmdを強制停止しました。停止理由はtimeoutですが、実態としては停止に成功しています。

4-2. 手動upgradeでテーブルが作成されました

停止後に次を実行しました。

/cm/local/apps/cmd/sbin/cmdaemonctl upgrade
echo $?

終了コードは0でした。続けて次を確認しました。

mysql -u root -p -e "USE cmdaemon; SHOW TABLES LIKE 'NVLinkSDNPartitionz';"

その結果、NVLinkSDNPartitionzテーブルが存在することを確認できました。

この結果は決定的です。原因は、やはりcmdaemonctl upgrade未実行または未反映でした。

4-3. 根本原因

根本原因は次のように整理できます。

  • cmdはNVLinkSDNPartitionzを前提に動作していた
  • しかしDBにそのテーブルが存在しなかった
  • cmdaemonctl upgradeを手動実行すると、そのテーブルが作成された
  • よって、本件はDB migration未反映が直接原因である

5. cmd再起動後の確認

upgrade後にcmdを再起動したところ、cmd.serviceはactive (running)で正常起動しました。

さらに、直近のjournalctl -u cmdには、それまで大量に出ていた

  • Table 'cmdaemon.NVLinkSDNPartitionz' doesn't exist (1146)

が現れなくなりました。

したがって、今回の主障害はここで解消したと判断できます。

5-1. 解決条件

今回の解決条件は次の2点でした。

  1. cmdaemonctl upgradeが0で成功すること
  2. SHOW TABLES LIKE 'NVLinkSDNPartitionz'でテーブル存在を確認できること

この2点が揃った時点で、1146エラーが止まる論理が成立します。実際、再起動後のログでもそれを確認できました。

6. 今回の教訓

今回のポイントは、dpkg --configure -aだけでは十分ではなかったことです。dpkgの状態が正常化しても、cmdaemonのDB migrationが完了していない場合があります。

したがって、同様の症状では次の順で見るのが合理的です。

6-1. 確認順序

  1. dpkg --auditでpackage状態を確認します
  2. dpkg --configure -a / apt-get -f installでpackage不整合を解消します
  3. SHOW TABLES LIKE 'NVLinkSDNPartitionz'でテーブル存在を確認します
  4. cmdaemon.postinstを見て、upgradeの仕組みを確認します
  5. 必要ならcmd停止後にcmdaemonctl upgradeを手動実行します
  6. cmd再起動後に1146が消えたことを確認します

6-2. 実際に有効だったコマンド

dpkg --audit
dpkg --configure -a
apt-get -f install

dpkg -l | egrep 'cmdaemon|bcm'
mysql -u root -p -e "USE cmdaemon; SHOW TABLES LIKE 'NVLinkSDNPartitionz';"

sed -n '1,260p' /var/lib/dpkg/info/cmdaemon.postinst
/cm/local/apps/cmd/sbin/cmdaemonctl --help

systemctl stop cmd
/cm/local/apps/cmd/sbin/cmdaemonctl upgrade
systemctl start cmd

journalctl -u cmd -n 100 --no-pager

7. まとめ

今回の障害は、cmdプロセス自体の問題ではなく、cmdaemonDBスキーマの不整合が本質でした。観察結果は一貫しています。

  • cmdはNVLinkSDNPartitionzを参照していた
  • DBにはそのテーブルが無かった
  • cmdaemonctl upgrade実行後にそのテーブルが作成された
  • その後、1146エラーは消えた

同様の事象では、cmdの再起動やdpkg修復だけで終わらせず、必要なテーブルが本当に存在するかをDBで確認することが重要です。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?