Jetson Orin/Nanoにおけるネットワークカメラの自動起動設定：systemdとethtoolによるデバイス待機手法

エッジAIカメラや監視システムの開発において、NVIDIA Jetson NanoやJetson Orinシリーズにネットワークカメラ（IPカメラ、GigE Visionカメラ、PoEカメラなど）を接続し、映像を取得・推論する構成は広く採用されています。

しかし、開発環境で動作確認を終え、実機を再起動させた際に、Jetson起動直後に実行されるはずの映像取得プログラムが立ち上がらず、カメラに接続できないという事象が発生することがあります。

起動後に手動でプログラムを再実行すると正常に動作する場合、これは起動時の処理タイミングに起因する問題である可能性が高いと言えます。

本記事では、Convergence Labでの運用経験に基づき、この問題の原因と、Jetson Orin環境特有のネットワーク事象、そしてsystemdとethtoolを用いた実用的な対処法について解説します。

1. 現象：自動起動時のネットワーク到達不可エラー

自作の映像取得アプリケーションやROSノードなどをsystemdで自動起動させようとした際、起動に失敗し、systemctl statusで以下のようなエラーログが確認されることがあります。

Error: RTSP connection failed. Network unreachable.  
# または  
netlink error: no such device

.serviceファイルにおいて After=network-manager.service を指定しているにもかかわらず、なぜこのようなエラーが発生するのでしょうか。

この原因の一つとして、ソフトウェアの起動状態とハードウェアの認識状態のタイムラグが挙げられます。

network-manager.serviceが起動完了（Active）となった状態は、Jetson内のネットワーク管理ソフトウェアの準備が整ったことを示しています。しかし、OSが物理的なLANポート（NIC）を完全に認識し、デバイスファイルとしての準備が完了するまでには、わずかな遅延が存在します。

プログラム側がカメラにアクセスを試みた瞬間に物理レイヤーの準備が間に合っていない場合、通信経路が未確立であるため「デバイスが存在しない」としてエラーになります。

2. 対策1：物理ネットワークインターフェースの起動待機

この問題を解消するためには、抽象的なネットワークサービスの起動を待つだけでなく、カメラが接続されている「物理デバイス（LANポート）」自体の認識を待機するようsystemdに設定を行います。

ステップ1：インターフェース名の特定

ターミナルで以下のコマンドを実行し、カメラが接続されているインターフェース名（例：eth0、eth1）を確認します。

$ ip link

ステップ2：.service ユニットファイルの修正

カメラが eth0 に接続されていると仮定します。systemd上では、この物理デバイスは sys-subsystem-net-devices-eth0.device というデバイスユニットとして扱われます。

対象サービスの .service ファイルの [Unit] セクションに以下の記述を追記または修正します。

[Unit]  
Description=Network Camera Application  
# 物理デバイスへの依存を追加  
Requires=sys-subsystem-net-devices-eth0.device  
After=network-manager.service sys-subsystem-net-devices-eth0.device

これにより、「eth0デバイスがシステムに認識されるまで、該当アプリケーションの起動を保留する」という動作が適用されます。

3. 対策2：【Orin環境】オートネゴシエーションの無効化と ethtool による速度固定

物理デバイスの認識を待機する設定に加えて、Jetson Orinシリーズ（AGX, NX, Nano）にGigEカメラなどを直結する場合、オートネゴシエーション（通信速度の自動調整）の不安定さに起因する問題が発生することがあります。

Jetsonとカメラを接続した際、通信速度のネゴシエーションに時間がかかりリンクアップが遅延する、あるいは1Gbps対応のカメラであるにもかかわらず100Mbpsでリンクしてしまい映像のコマ落ちが発生する、といった事例があります。

nmcli 等でOS側の設定を固定する方法もありますが、ドライバの挙動によって再起動時に設定がリセットされるケースがあるため、ethtool を使用して物理NICのステータスを直接固定する手法がより確実です。

現在の状態は以下のコマンドで確認できます。

$ sudo ethtool eth0

通信速度を「オートネゴシエーション無効、1000Mbps(1Gbps)、全二重」に固定する場合は、以下のコマンドを実行します。

$ sudo ethtool -s eth0 speed 1000 duplex full autoneg off

4. 対策3：systemdへの組み込みと起動マージンの確保

これまでの対策（NICの待機、ethtoolによる固定）に加え、**カメラ自体のOSが起動し、映像配信の準備が完了するまでの待機時間（マージン）**を設けることで、より安定したシステム構築が可能になります。

これらの設定を、対象の .service ファイルの [Service] セクションに ExecStartPre として集約します。

[Service]  
Type=simple  
User=root

# 処理1: プログラム起動前にethtoolでリンク速度と全二重を固定する  
ExecStartPre=+/sbin/ethtool -s eth0 speed 1000 duplex full autoneg off

# 処理2: カメラ本体の起動とネットワーク確立を待機する（環境に合わせて秒数を調整）  
ExecStartPre=/bin/sleep 5

# メインプログラムの実行  
ExecStart=/usr/local/bin/camera_app

(※ ethtool は実行にroot権限を要するため、ServiceのUserがroot以外の場合は + 記号を付与して ExecStartPre=+/sbin/ethtool… と記述し、特権で実行させます。)

この構成により、ethtool による物理層の安定化と、sleep によるデバイス間の起動遅延の吸収を同時に行うことができます。実運用環境において発生し得る様々なタイミングの問題に対処するための、実践的な手法と言えます。

まとめ

Jetson環境においてネットワークカメラ関連のサービスが自動起動に失敗する場合、以下の3点を軸に対策を検討してください。

1. 物理デバイスの待機: .serviceの [Unit] セクションにて、対象NICの .device を Requires および After に指定する。
2. ethtoolによる物理層の固定: [Service] セクションの ExecStartPre にて、ethtool を用いオートネゴシエーションをオフにし通信速度を固定する。
3. 起動マージンの確保: 同様に ExecStartPre=/bin/sleep を設定し、カメラ側の配信準備が整うのを待機する。

ソフトウェア上の依存関係だけでなく、ハードウェアの物理的な初期化プロセスやデバイス固有の起動時間を考慮した設計を行うことで、エッジAIシステムの稼働安定性は向上します。

Convergence Labでは、今後もエッジコンピューティング実装における技術情報やノウハウを発信してまいります。システム構築に関する課題がございましたら、過去の記事も併せてご参照ください。