Ubuntu Server24.04起動時にsystemd-networkd-wait-online.serviceで待たされる問題を解消する。

# はじめに
先日`Ubuntu`の新しいLTSとなる`Ubuntu 24.04`が公開されたため、自宅のサーバOSを`Ubuntu Server 24.04`に入れ替えていたのですが、起動時に`systemd-networkd-wait-online.service`で２分ほど待たされるようになったため、待たされないようにした方法を残しておこうと思います。

# systemd-networkd-wait-online.serviceで待たされる問題
私は基本的にはテスト用のサーバ用途で使うことが多いため、`Ubuntu Server`を使っており、たまに`VirtualBox`や`VMware Workstation Player`などGUIで操作するアプリケーションを使うこともあるため、邪道かもしれませんが、`Ubuntu Server`にGUI環境もインストールして使っています。

問題は、`Ubuntu Server 24.04`にデスクトップサービスや`xrdp`をインストール後、再起動した際に発生しました。

起動時に`systemd-networkd-wait-online.service`のチェックに失敗し、以下のようにデフォルトのタイムアウト時間となる2分待機させられてしまうため、起動はしますが時間がかかってしまいます。

![Monosnap_20240512_104251.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569912/3e110bb4-a30b-c34b-1481-ce5c130eb477.png)

ちなみに`systemd-networkd-wait-online.service`はネットワークが起動する前に他のアプリケーションが起動して、ネットワークが見つからずにエラーとなってしまうことを防ぐためにネットワークが起動し終わるまでに待機するためのサービスのようです。

タイムアウトとなるため、ネットワークが起動できていないかと思いきや、そんなことはなく、起動後はサーバに繋がるため、ネットワークサービス自体には問題がないようです。

以下調査した結果をまとめていこうと思いますが、対処法だけ知りたい方は以下にお進みください。

- [対処法その1：systemd-networkd-wait-online.serviceの停止](#対処法その1systemd-networkd-wait-onlineserviceの停止)
- [対処法その2：レンダリングエンジンをnetworkdに戻す](#対処法その2レンダリングエンジンをnetworkdに戻す)
- [対処法その3：systemd-networkdの設定も行う](#対処法その3systemd-networkdの設定も行う)

# 原因調査
調べてみると、`systemd-networkd-wait-online.service`を止めてしまう方法や、LANが繋がっていないインタフェースを除外する方法等が出てきましたが、止めてしまうとネットワークが起動し終わる前に他のサービスが起動してしまうこともありうるのでできれば止めたくありません。

また、LANが繋がっていないインタフェースを除外しようにも、１つのインタフェースだけでも問題が発生したため、今回の問題とは事象が異なるようです。

ということで、他の方法がないか色々と調べた結果を以下に示します。

## 原因切り分け
事象再現のため、`VirtualBox`で同様の構成を構築してみたところ、2分待たされる問題が発生しました。

|項目|内容|
|:--|:--|
|OS|Ubuntu Server 24.04 LTS|
|インタフェース数|1つ（物理ネットワークにブリッジ）|
|主なインストールアプリケーション|ubuntu-desktop、xrdp|

GUI系のサービスをインストールするまでは2分待たされることはなかったので、GUI系サービスが影響しているだろうというところまで分かりました。

また、最初からGUI環境もインストールされる`Ubuntu Desktop 24.04 LTS`に`ubuntu-desktop`や`xrdp`をインストールして再起動を行ってみたところ、`Ubuntu Desktop`では2分待たされることはありませんでした。

## Ubuntu ServerとUbuntu Desktopの違い
どういうこっちゃ？と思いつつ、`Ubuntu Server`と`Ubuntu Desktop`について調べてみると、`Ubuntu Server`と`Ubuntu Desktop`ではデフォルトのネットワークサービスが異なるとのこと。

|OS|デフォルトネットワークサービス|
|:--|:--|
|Ubuntu Server 24.04 LTS|systemd-networkd|
|Ubuntu Desktop 24.04 LTS|NetworkManager|

それぞれネットワーク系サービスのインストールと起動有無をまとめたものが以下となります。

|ネットワーク系サービス|Ubuntu Server 24.04 LTS|Ubuntu Desktop 24.04 LTS|
|:--|:--|:--|
|systemd-networkd|自動起動|未起動|
|NetworkManager|未インストール|自動起動|
|systemd-networkd-wait-online|自動起動|未起動|
|NetworkManager-wait-online|未インストール|自動起動|

`Ubuntu Desktop`はサービスとしては使われていませんが、インストールはされている状態のようです。

`Ubuntu Server`は`NetworkManager`がそもそもインストールされていない状態のようです。

## 問題の原因仮説
途中で飽きてしまい、根本原因の裏取りまで行きつかなかったので仮説までとしておきます。

`NetworkManager`は以下のようにGUIでネットワークインタフェースの設定等行う際のサービスとしても使われています。

![Monosnap_20240512_162214.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569912/a312bb04-482a-87a5-caec-45d790a5cfb0.png)

`Ubuntu 24.04`ではネットワークは`NetPlan`の設定と統合されたようなので、`Ubuntu Server`でも、`Ubuntu Desktop`でも、`/etc/netplan`配下に`NetPlan`のファイルが置かれていればネットワークが設定されます。

しかし、`systemd-networkd-wait-online`サービスでは`NetworkManager`で起動されたネットワークはおそらく管理外のため起動判定されず、タイムアウトまでの2分間待機する動作となっていると思われます。

今回は、`Ubuntu Server`にGUI環境をインストールしたタイミングで`NetworkManager`がインストールされたことで、`NetworkManager`が動き出し、おそらくデフォルトのネットワークレンダリングエンジンが`NetworkManager`に変わったことで`systemd-networkd`の起動状態を監視する`systemd-networkd-wait-online`が正常に判定できず、タイムアウトまで待ってしまったということなのかと思われます。

## 対処法その1：systemd-networkd-wait-online.serviceの停止
おそらくGUI環境を構築すると`NetworkManager`がデフォルトのネットワークレンダリングエンジンとなることでチェックできずにタイムアウトまで待つことになるため、そもそもの原因となる`systemd-networkd-wait-online.service`を止めてしまう方法となります。

`NetworkManager`でネットワークの起動は問題無くでき、`NetworkManager-wait-online.service`といったサービスもあるため、`systemd-networkd-wait-online.service`を止めてしまってもおそらく問題ないと思いますが、停止する場合はしっかりと検証してから行うようにしてください。

```bash:systemd-networkd-wait-online.serviceの停止
systemctl disable --now systemd-networkd-wait-online.service
```

## 対処法その2：レンダリングエンジンをnetworkdに戻す
ネットワークレンダリングエンジンが`NetworkManager`に変わることで問題が発生しているため、ネットワークレンダリングエンジンを`NetworkManager`から`networkd`に戻す方法となります。

`/etc/netplan`配下にデフォルトで生成されるyamlファイル（今回の場合、`50-cloud-init.yaml`）を編集してレンダリングエンジンを明示的に記載することにより、`systemd-networkd`で動くようになります。

```yaml:/etc/netplan/50-cloud-init.yamlの編集
network:
    renderer: networkd        ←左記追加
    ethernets:
        enp0s3:
        （以下略）
```

上記設定を行うことで`NetworkManager`から`systemd-networkd`に変わってしまうことから、GUI上からのネットワーク設定はできなくなるためご注意ください。
※アイコンもネットワーク設定項目も無くなる。

## 対処法その3：systemd-networkdの設定も行う
`systemd-networkd`の状態は`networkctl`コマンドで認識されているネットワークの管理状態などを確認することができます。

```bash:networkctlの結果
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp0s3 ether    routable    unmanaged

2 links listed.
```

仮説ですが、GUI環境をインストールすることでデフォルトネットワークエンジンが`NetworkManager`に変わった際、`systemd-networkd`が`/etc/netplan`配下のファイルでネットワークの判定ができなくなることで失敗しているものと思われます。

GUI環境をインストールするまでは`networkctl`の結果が、`systemd-networkd`で管理されていない`unmanaged`の状態でも起動判定してくれるようですが、GUI環境をインストールしてしまうと、管理状態のネットワークにしないといけないようなので、`NetworkManager`の設定はそのままに、本来の`systemd-networkd`のやり方で`systemd-networkd`の設定も追加する方法となります。

本来、`systemd-networkd`の設定を行う場合、`/etc/systemd/network`配下に`〜.network`ファイルを作成することで`systemd-networkd`の管理下になるため、新規で`〜.network`ファイルを作成します。

今回はIPアドレスを固定させたかったため、`50-wired.network`というファイル名で以下のように設定しました。

```bash:/etc/systemd/network/50-wired.network
[Match]
Name=enp0s3

[Network]
DHCP=no
DNS=8.8.8.8
DNS=8.8.4.4
NTP=ntp.nict.jp

[Address]
Address=192.168.0.51/24

[Route]
Gateway=192.168.0.1
```

設定後、ネットワークをリロードします。

```bash:ネットワークリロード
networkctl reload
```

リロード後、再度`networkctl`コマンドを実行して、`enp0s3`が`configured`になっていればOKです。

```bash:設定後のnetworkctlの結果
IDX LINK   TYPE     OPERATIONAL SETUP
  1 lo     loopback carrier     unmanaged
  2 enp0s3 ether    routable    configured

2 links listed.
```

ついでに、`networkctl status enp0s3`と実行すると、設定したNTPやDNSも確認することができます。

```bash:networkctl status enp0s3の結果
● 2: enp0s3
                   Link File: /usr/lib/systemd/network/99-default.link
                Network File: /etc/systemd/network/50-wired.network
                       State: routable (configured)
                Online state: online
                        Type: ether
                        Path: pci-0000:00:03.0
                      Driver: e1000
                      Vendor: Intel Corporation
                       Model: 82540EM Gigabit Ethernet Controller (PRO/1000 MT Desktop Adapter)
            Hardware Address: 08:00:27:6a:09:7d (PCS Systemtechnik GmbH)
                         MTU: 1500 (min: 46, max: 16110)
                       QDisc: pfifo_fast
IPv6 Address Generation Mode: eui64
    Number of Queues (Tx/Rx): 1/1
            Auto negotiation: yes
                       Speed: 1Gbps
                      Duplex: full
                        Port: tp
                     Address: 192.168.0.51
                              2400:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx
                              fe80::a00:27ff:fe6a:97d
                     Gateway: 192.168.0.1
                              fe80::2a0:deff:fe7d:792
                         DNS: 8.8.8.8
                              8.8.4.4
                              2400:4051:e01:d500::1
                         NTP: ntp.nict.jp
                              2404:1a8:1102::b
                              2404:1a8:1102::a
           Activation Policy: up
         Required For Online: yes
           DHCP6 Client IAID: 0xe2343f3e
           DHCP6 Client DUID: DUID-EN/Vendor:0000ab11e4a5cff67bd4f086

 5月 12 18:46:08 vmware systemd-networkd[696]: enp0s3: Configuring with /etc/systemd/network/50-wired.network.
 5月 12 18:46:08 vmware systemd-networkd[696]: enp0s3: Link UP
 5月 12 18:46:08 vmware systemd-networkd[696]: enp0s3: Gained carrier
 5月 12 18:46:09 vmware systemd-networkd[696]: enp0s3: Gained IPv6LL
```

今回の設定の場合、GUI上からは以下のように`netplan-enp0s3`と`enp0s3`の2つのネットワーク設定が存在し、赤枠の`enp0s3`の設定が有効となっていることが確認できます。

![Monosnap_20240512_185441.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/569912/5dd289ff-a0f5-d514-8b99-bbf3aae42f28.png)

この場合、`NetworkManager`も有効であり、`systemd-networkd`の設定も行われていることから、GUI上からネットワークの設定も行うことができ、OS起動時に`systemd-networkd-wait-online.service`で待たされることも無くなります。

設定ファイルは`NetworkManager`と`systemd-networkd`の二重で管理しているように見えるため、運用する場合は気をつける必要がありますが、特にサービス停止等行わずに対応できるため、他の対処法よりは動作検証や影響調査が少なくて済むのではないかと思います。

# おわりに
`Ubuntu 24.04`は公開されてから１ヶ月も経っておらず、情報もまだ少なかったので苦労しましたが、調査をしたことで、`Ubuntu 24.04`のネットワークサービスの構成や`Ubuntu Server`と`Ubuntu Desktop`の違いなど、なんとなく知ることができました。

以前のLTSとなる`Ubuntu 22.04`から比較しても色々と変わっているところが多く、ネットワークインストールがどうしてもうまくいかなかったり、まだ使いたいアプリが対応していなかったりと、問題は山積みですが、自宅サーバなのでぼちぼち改善していこうと思います。