ここ最近、ラズパイ4B(Raspberry Pi 4 model B)の断続的なプチフリーズ（一時的フリーズ）に悩まされていました。自分のラズパイ4Bは、以前のこちらの記事で紹介したように Ubuntu Server 22.04 LTS を使っていますが、SSHリモート接続のVSCodeターミナルも断続的にフリーズしてキーボード入力できなくなったり、USBカメラ動画も１分毎にプチフリーズを繰り返していたりしていて、原因追及に長時間を費やしていました。
ネットの情報や無料版ChatGPTの情報では、ラズパイ4BのUSBポートの電力供給不足とか、USB-SSDのLPM問題とか、DHCPではなく固定IPにした方が良いとか、いろいろあってどれも解決には至らず、１か月以上時間を費やしましたが、今回はやっと解決するに至ったのです。
それは意外とつまらない単純な原因で拍子抜けでしたが、出費を伴う痛い結果でした。
ただ、今回の件で、Linux Ubuntu のログ確認方法や、ネットワーク設定方法、パッケージの自動更新設定やタイムサーバーの自動更新設定などが出来るようになったので、Linux Ubuntuをより理解できて、ある意味収穫でした。
そんなわけで、今回学んだことを綴ってみます。
あくまでも個人の備忘録です。
１．現在の自分の環境
ラズパイ4B環境
まずは、自分のRaspberry Pi 4 model B のブートローダーバージョンは以下です。
~$ sudo rpi-eeprom-update
BOOTLOADER: up to date
CURRENT: 2022年 1月 25日 火曜日 14:30:41 UTC (1643121041)
LATEST: 2022年 1月 25日 火曜日 14:30:41 UTC (1643121041)
RELEASE: default (/lib/firmware/raspberrypi/bootloader/default)
Use raspi-config to change the release.
VL805_FW: Dedicated VL805 EEPROM
VL805: up to date
CURRENT: 000138a1
LATEST: 000138a1
ということで、ブートローダーは2023年4月時点では最新版です。
次に、OSのバージョンは以下です。
~$ cat /etc/os-release PRETTY_NAME="Ubuntu 22.04.2 LTS" NAME="Ubuntu" VERSION_ID="22.04" VERSION="22.04.2 LTS (Jammy Jellyfish)" VERSION_CODENAME=jammy ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=jammy
これも、2023年4月時点のUbuntu 22.04系では最新版です。
次にカーネルのバージョンは以下です。
~$ cat /proc/version Linux version 5.15.0-1027-raspi (buildd@bos02-arm64-011) (gcc (Ubuntu 11.3.0-1ubuntu1~22.04) 11.3.0, GNU ld (GNU Binutils for Ubuntu) 2.38) #29-Ubuntu SMP PREEMPT Mon Apr 3 10:12:21 UTC 2023
パソコン環境
自分の現在のパソコン環境は以下です。
Windows 10 Pro 22H2
Visual Studio Code ver 1.78.0 (SSHリモート）
２．とにかくまずはシステムログ確認
プチフリーズ対策については、ネットの情報を集めたり、ChatGPTに聞いてみたりしましたが、なかなか解決できませんでした。
その中でも共通して言われていたのが、システムログや通信ログを詳細に確認せよということでした。
私の場合はラズパイ4BをWindowsパソコンでSSHリモート接続し、VSCodeのターミナルでプチフリーズが断続的に発生してキーボード入力ができなくなることが頻繁にあったので、ラズパイ4Bを起動したら以下のコマンドでシステムや通信のログをリアルタイムで確認することにしました。
sudo tail -f /var/log/syslog
すると、ログの最終行が更新される度にVSCodeのターミナルに表示されるようになります。
（「Ctrl」＋「c」キーで終了できます。）
その時に矢印キーなどを１秒毎に打つと、以下のように表示されると思います。
^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[C^[[
これをフリーズするまで打ち込みます。
そして、フリーズが発生して、少々待つと以下のようにログ表示されました。
Apr 21 20:15:07 xxxxxxxx systemd-networkd[758]: eth0: Lost carrier Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Withdrawing address record for 192.168.0.5 on eth0. Apr 21 20:15:07 xxxxxxxx systemd-networkd[758]: eth0: DHCP lease lost Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.5. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Interface eth0.IPv4 no longer relevant for mDNS. Apr 21 20:15:07 xxxxxxxx systemd-networkd[758]: eth0: DHCPv6 lease lost Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Withdrawing address record for 1234:5678:9abc:def1:2345:6789:abcd:ef01 on eth0. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Leaving mDNS multicast group on interface eth0.IPv6 with address 1234:5678:9abc:def1:2345:6789:abcd:ef01. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::2345:6789:abcd:ef01. Apr 21 20:15:07 xxxxxxxx systemd-timesyncd[647]: No network connectivity, watching for changes. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Registering new address record for fe80::2345:6789:abcd:ef01 on eth0.*. Apr 21 20:15:10 xxxxxxxx kernel: [ 137.564737] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Apr 21 20:15:10 xxxxxxxx systemd-networkd[758]: eth0: Gained carrier Apr 21 20:15:10 xxxxxxxx systemd-timesyncd[647]: Network configuration changed, trying to establish connection. Apr 21 20:15:11 xxxxxxxx systemd-networkd[758]: eth0: DHCPv4 address 192.168.0.5/24 via 192.168.0.1 Apr 21 20:15:11 xxxxxxxx avahi-daemon[795]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.5. Apr 21 20:15:11 xxxxxxxx avahi-daemon[795]: New relevant interface eth0.IPv4 for mDNS. Apr 21 20:15:11 xxxxxxxx systemd-timesyncd[647]: Network configuration changed, trying to establish connection. Apr 21 20:15:11 xxxxxxxx avahi-daemon[795]: Registering new address record for 192.168.0.5 on eth0.IPv4. Apr 21 20:15:11 xxxxxxxx systemd-timesyncd[647]: Initial synchronization to time server 185.125.190.56:123 (ntp.ubuntu.com). Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::2345:6789:abcd:ef01. Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Joining mDNS multicast group on interface eth0.IPv6 with address 1234:5678:9abc:def1:2345:6789:abcd:ef01. Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Registering new address record for 1234:5678:9abc:def1:2345:6789:abcd:ef01 on eth0.*. Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Withdrawing address record for fe80::2345:6789:abcd:ef01 on eth0. ～以下略～
ターミナルが固まって文字入力ができなくなると、決まってこのログが表示されることが分かりました。
つまり、IPv4とIPv6の両方ともDHCPがlostしているということです。
そして、その時にNTPタイムサーバーへの接続も失敗していることがわかります。
最初はNTPサーバーへアクセスしていることがプチフリーズに影響しているのかと疑って、systemd-timesyncd の停止を試みましたが、これは的外れでした。
ということは、どうやらルーターから自動的に払われるDHCPの取得が失敗していることが原因のようです。
ただ、不思議だったのは、lostするのは一時的で、すぐに復活していて、NTPサーバーへの再接続も成功していることです。
これが約１分毎に頻繁に発生しているんです。
そんなわけで、この原因をChatGPTに聞いてみたり、ネットの情報を漁ってみたりしました。
そこで見つけた解決策はDHCPを停止して、固定IPにすることでした。（これは後に的外れと判ったのですが…）
３．的外れだったこと
この３章ではプチフリーズの解決には至らず、的外れだったことを綴っていきます。
ただ、個人的にはとても勉強になったので、備忘録として記録しておきます。
3-01. USB電力供給問題？
まず、プチフリーズの原因として、最初に疑ったのはラズパイ4BのUSBポートの電力供給不足です。
それには、ハード的なものと、LPMという省電力設定などが考えられました。
3-01-01. ハード側によるSSDへのUSB電力供給不足？
ネットの情報でまず見つかった断続的なプチフリーズの原因は、ハードウェアとしてのSSDへのUSB電源供給不足でした。
以前、こちらの記事で紹介したように自分のラズパイ4Bはmicro SDブートからUSB-SSDブートに変更しました。使っているUSB-SSDはUSBバスパワーで動作するこれです。
【メーカー】 BUFFALO (バッファロー)
【名称】 SSD 外付け 250GB 超小型 コンパクト ポータブル PS5/PS4対応(メーカー動作確認済) USB3.2Gen1 ブラック
【型式】 SSD-PUT250U3-B/N
（図03-01-01-01）
Raspi4Bのブートに使用しているUSB-SSD
ラズパイのUSB3.0ポートに直挿ししたSSDでは、もしかしたら電源供給不足によってアクセスが一時的に制限されるようなことが有り得そうと思って疑いました。
そこで、外部電源供給可能なUSB3.0ハブを購入しました。
以下の物です。
「エレコム U3H-T410SBK」
（図03-01-01-02）
外部電源供給できるUSB3.0ハブ
いきなり結論を言うと、残念ながらこれではプチフリーズは解消されませんでした。ちょっとは期待したんですけどね。
ただ、一時はもっと高級なSSDを買わないとダメなのかなとも思いましたが、これを購入したことにより、ラズパイ4BのUSBポート電力不足は当分心配無用になったのでヨシとします。
3-01-02. LPM問題？
次に、USB-SSDを使った場合のプチフリーズの原因は、ネットの情報や無料版ChatGPTの多くがUSBポートのLPM問題を上げていました。
LPMとは Link Power Management の略で、ソフトウェアの設定による省電力機能だそうです。これが動作していたと考えられました。
まず、LPMを解除するには多くの情報では GRUB というファイルの設定を変えよという指摘が多かったのですが、Ubuntu 22.04 では /etc/default/grub というファイルは存在しませんでした。
代わりに、/etc/default/grub.d/50-cloudimg-settings.cfg というファイルを見つけました。
試しにそのファイルを以下のように設定してみました。
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash usbcore.autosuspend=-1"
でも、残念ながらプチフリーズは解消しませんでした。
また、/etc/systemd/system.conf を設定するという情報もあったのですが、これも的外れでした。
どうやら、Ubuntu 22.04 ではデフォルトでLPMが解除されているようでした。
次でも述べていますが、USBポート電源供給量を確認してみても明らかでした。
3-01-03. USBポートの電源供給量の確認
まず、ラズパイ4BのUSB3.0ポートにUSB-SSDを直挿ししてVSCodeでSSHリモート接続します。
そして、ターミナルで次のコマンドを打ってラズパイ4BのUSBポートの電源供給量を確認してみます。
lsusb -v | grep -e 'MaxPower' -e 'Bus [0-9]'
すると、以下のように表示されました。
~$ lsusb -v | grep -e 'MaxPower' -e 'Bus [0-9]' Couldn't open device, some information will be missing Couldn't open device, some information will be missing Bus 003 Device 001: ID xxxx:xxxx Linux Foundation 2.0 root hub Couldn't open device, some information will be missing MaxPower 0mA Bus 002 Device 002: ID xxxx:xxxx BUFFALO INC. (formerly MelCo., Inc.) SSD-PUT/N MaxPower 896mA Couldn't open device, some information will be missing Bus 002 Device 001: ID xxxx:xxxx Linux Foundation 3.0 root hub MaxPower 0mA Bus 001 Device 002: ID xxxx:xxxx VIA Labs, Inc. Hub Couldn't open device, some information will be missing MaxPower 100mA Bus 001 Device 001: ID xxxx:xxxx Linux Foundation 2.0 root hub MaxPower 0mA
では、新たに購入した外部電源供給可能なUSB3.0ハブを使って同じようにしてみます。
すると、以下のように表示されました。
~$ lsusb -v | grep -e 'MaxPower' -e 'Bus [0-9]' Couldn't open device, some information will be missing Couldn't open device, some information will be missing Couldn't open device, some information will be missing Bus 003 Device 001: ID xxxx:xxxx Linux Foundation 2.0 root hub MaxPower 0mA Bus 002 Device 003: ID xxxx:xxxx BUFFALO INC. (formerly MelCo., Inc.) SSD-PUT/N MaxPower 896mA Couldn't open device, some information will be missing Bus 002 Device 002: ID xxxx:xxxx VIA Labs, Inc. VL813 Hub MaxPower 0mA Couldn't open device, some information will be missing Bus 002 Device 001: ID xxxx:xxxx Linux Foundation 3.0 root hub Couldn't open device, some information will be missing Couldn't open device, some information will be missing MaxPower 0mA Bus 001 Device 003: ID xxxx:xxxx VIA Labs, Inc. VL813 Hub MaxPower 0mA Bus 001 Device 002: ID xxxx:xxxx VIA Labs, Inc. Hub MaxPower 100mA Bus 001 Device 001: ID xxxx:xxxx Linux Foundation 2.0 root hub MaxPower 0mA
このように、USB-SSDの電源供給量は 896mA となっていて、USBハブでもラズパイ直挿しで変化ありませんでした。
3-01-04. /boot/config.txt のパラメータを書き換えてみる
ネットの情報や無料版ChatGPTでは、/boot/config.txt というファイルに以下のパラメータ
max_usb_current=1
を書き込むとUSB電源供給量を増やせるというネットの情報がありました。
ただ、これでもプチフリーズは解消されませんでした。
どうやらUbuntu 22.04ではデフォルトでこの設定らしいです。
以上から、プチフリーズの原因として考えられたUSBポートの電源供給不足は的外れだったということでした。
3-01-05. USBポートの速度表示
では、念のため、USBポートの転送速度を確認してみたいと思います。以下のコマンドです。
lsusb -t
まずは、USBハブ無しの場合、以下のようになりました。
~$ lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
次に、電源供給型USBハブを使った場合は以下のようになりました。
~$ lsusb -t /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=dwc2/1p, 480M /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 5000M |__ Port 1: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/4p, 480M
これからわかるように、USB-SSDは両者とも5000Mとなっているので、ラズパイ直挿しだろうが電源供給型USBハブを使おうが転送速度は変わらないという結果でした。
3-02. オートアップデートの影響？
そう言えば、ラズパイ4BにUbuntu Serverをインストールした際に、パッケージのオートアップデート（自動更新）設定があったのを思い出しました。
もしかしたら、これが頻繁に動作していることがプチフリーズの原因かなとも思われました。
まず、20auto-upgrades ファイルの設定確認してみます。
~$ cat /etc/apt/apt.conf.d/20auto-upgrades APT::Periodic::Update-Package-Lists "1"; APT::Periodic::Unattended-Upgrade "1";
このようにオートアップデートが動作していたのでviコマンドで以下のように編集して停止させました。
APT::Periodic::Update-Package-Lists "0"; APT::Periodic::Unattended-Upgrade "0";
その他、50unattended-upgrades ファイルについても以下のように変更しました。
Unattended-Upgrade::DevRelease "auto";
というところを、
Unattended-Upgrade::DevRelease "false";
に変更。
以上のようにオートアップデート設定を停止しましたが、結局プチフリーズは解消されず、これも的外れでした。
3-03. DHCPを停止して固定IP（Static IP）にする？
先ほどシステムログ確認で紹介したように、ラズパイ4BのシステムログではDHCPがlostしていました。
ネットの情報によると固定IP(Static IP)にすると解消されるはずとのことでした。
Ubuntu 22.04 では、固定IPにするにはnetplanを使うようです。
ネットの情報や無料版ChatGPTでは、/etc/systemd/networkd.conf を修正するような情報もあって混乱しますが、netplanで良いみたいです。
netplanについてはネットの情報では古い物から新しいものまでいろいろあって、最初はどれが正解なのかよくわかりませんでした。
ネット上では 99_config.yaml ファイルを書き換えるという情報があり、そのファイルを探しても見当たりませんでした。
/etc/netplan フォルダの中には 50-cloud-init.yaml というファイルしか存在せず、このファイルを編集していました。
しかし、以下の記事を読んでこのファイルを編集するのは誤りだということがわかりました。
https://qiita.com/yas-nyan/items/9033fb1d1037dcf9dba5
確かに、以下のnetplan公式ページにそう書かれていました。
https://netplan.readthedocs.io/en/latest/netplan-tutorial/
つまり、/etc/netplan/50-cloud-init.yaml ファイルは cloud-init によって書き換えられてしまうので、ユーザーが編集しても無意味なようです。
よって、ユーザー設定用に新たにyamlファイルを作成しなければならないということです。
そして、yamlファイル名はアルファベット順で 50-cloud-init.yaml より後になるようなファイル名にすれば良いみたいです。そうすれば、設定が更新されるようです。
ですから、99_config.yaml でも良いし、公式ページの例文の様に second-interface.yaml でも良いというわけです。
では、先ほども述べたように、以下のコマンドでシステムログを監視します。
sudo tail -f /var/log/syslog
すると、プチフリーズが発生した時に以下の様なメッセージが出ました。
Apr 21 20:15:07 xxxxxxxx systemd-networkd[758]: eth0: Lost carrier Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Withdrawing address record for 192.168.0.5 on eth0. Apr 21 20:15:07 xxxxxxxx systemd-networkd[758]: eth0: DHCP lease lost Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Leaving mDNS multicast group on interface eth0.IPv4 with address 192.168.0.5. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Interface eth0.IPv4 no longer relevant for mDNS. Apr 21 20:15:07 xxxxxxxx systemd-networkd[758]: eth0: DHCPv6 lease lost Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Withdrawing address record for 1234:5678:9abc:def1:2345:6789:abcd:ef01 on eth0. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Leaving mDNS multicast group on interface eth0.IPv6 with address 1234:5678:9abc:def1:2345:6789:abcd:ef01. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Joining mDNS multicast group on interface eth0.IPv6 with address fe80::2345:6789:abcd:ef01. Apr 21 20:15:07 xxxxxxxx systemd-timesyncd[647]: No network connectivity, watching for changes. Apr 21 20:15:07 xxxxxxxx avahi-daemon[795]: Registering new address record for fe80::2345:6789:abcd:ef01 on eth0.*. Apr 21 20:15:10 xxxxxxxx kernel: [ 137.564737] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx Apr 21 20:15:10 xxxxxxxx systemd-networkd[758]: eth0: Gained carrier Apr 21 20:15:10 xxxxxxxx systemd-timesyncd[647]: Network configuration changed, trying to establish connection. Apr 21 20:15:11 xxxxxxxx systemd-networkd[758]: eth0: DHCPv4 address 192.168.0.5/24 via 192.168.0.1 Apr 21 20:15:11 xxxxxxxx avahi-daemon[795]: Joining mDNS multicast group on interface eth0.IPv4 with address 192.168.0.5. Apr 21 20:15:11 xxxxxxxx avahi-daemon[795]: New relevant interface eth0.IPv4 for mDNS. Apr 21 20:15:11 xxxxxxxx systemd-timesyncd[647]: Network configuration changed, trying to establish connection. Apr 21 20:15:11 xxxxxxxx avahi-daemon[795]: Registering new address record for 192.168.0.5 on eth0.IPv4. Apr 21 20:15:11 xxxxxxxx systemd-timesyncd[647]: Initial synchronization to time server 185.125.190.56:123 (ntp.ubuntu.com). Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Leaving mDNS multicast group on interface eth0.IPv6 with address fe80::2345:6789:abcd:ef01. Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Joining mDNS multicast group on interface eth0.IPv6 with address 1234:5678:9abc:def1:2345:6789:abcd:ef01. Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Registering new address record for 1234:5678:9abc:def1:2345:6789:abcd:ef01 on eth0.*. Apr 21 20:15:12 xxxxxxxx avahi-daemon[795]: Withdrawing address record for fe80::2345:6789:abcd:ef01 on eth0.
このように、最初に systemd-networkd で eth0: Lost carrier となり、続いて eth0: DHCP lease lost となり、そして続いて eth0: DHCPv6 lease lost となっていることがわかります。
これは、IPv4 と IPv6 の両方ともルーターからのDHCP取得が失敗していることを意味しているようです。
そこで、解決策をネット検索したり、ChatGPTに聞いてみると、固定IP(Static IP)にすれば解消されるという情報を得ました。
そこで、netplan公式例文に習って、新たにviエディタで /etc/netplan/second-interface.yaml ファイルを作成し、IPv4 と IPv6 のDHCPを停止し、固定IP設定で以下のように記述してみました。
（正直言って、この設定方法は自分でもよくわかっていません）
network:
version: 2
ethernets:
eth0:
dhcp4: no
dhcp6: no
optional: yes
accept-ra: no
addresses:
- 192.168.0.18/24
- "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64"
nameservers:
addresses:
- 192.168.0.1
- xxx.xxx.xxx.xxx #ルーターに表示されたDNSサーバーアドレス(ipv4)
- xxx.xxx.xxx.xxx #ルーターに表示されたDNSサーバーアドレス(ipv4)
- "fe80::xxxx:xxxx:xxxx:xxxx"
- "xxxx:xxxx:xxxx:xxxx::1" #ルーターに表示されたDNSサーバーアドレス(ipv6)
- "xxxx:xxxx:xxxx:xxxx::3" #ルーターに表示されたDNSサーバーアドレス(ipv6)
- 8.8.8.8
- 8.8.4.4
- "2001:4860:4860::8888"
- "2001:4860:4860::8844"
routes:
- to: default
via: 192.168.0.1
metric: 100
- to: default
via: "xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx"
このファイルを保存したら、以下のコマンドでnetplanを有効にします。
sudo netplan apply
その後、再度システムログを監視します。
sudo tail -f /var/log/syslog
これで、IPv4 のlostメッセージは無くなったのですが、IPv6の方、DHCPv6 のlostが解消されませんでした。
IPv6のデフォルトゲートウェイの設定が間違えているのかと思い、fe80から始まるものではなく、ルーターに表示されている2000番台から始まるアドレスに書き換えてもダメでした。
これはあらゆるパターンを試しましたがどれも的外れでした。
でも、ラズパイ4B Ubuntuで固定IPにする方法がわかったので、勉強にはなりましたね。
3-04. systemd-timesyncd が原因？
さきほど紹介したシステムログでは、DHCPがlostした後、決まってタイムサーバーへのアクセスが失敗していることがわかりました。
systemd-timesyncd が動いていて、かなり頻繁にタイムサーバーにアクセスしてラズパイの時刻を自動修正していることが分かりました。
そして、もしかして、これが原因かもと思い、時刻同期を停止してみました。
（※ただし、SSHリモートなど思わぬ不具合が発生する場合があるので、十分注意する必要があります。）
まず、以下コマンドで状態確認します。
systemctl status systemd-timesyncd
このようになります。
~$ systemctl status systemd-timesyncd ● systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; enabled; vendor preset: enabled) Active: active (running) since Mon 2023-04-08 21:49:14 JST; 7h ago Docs: man:systemd-timesyncd.service(8) Main PID: 648 (systemd-timesyn) Status: "Initial synchronization to time server [2620:2d:4000:1::3f]:123 (ntp.ubuntu.com)." Tasks: 2 (limit: 4415) Memory: 1.3M CPU: 252ms CGroup: /system.slice/systemd-timesyncd.service └─648 /lib/systemd/systemd-timesyncd
デフォルトでは、ntp.ubuntu.com がタイムサーバーでした。
では、これを以下のコマンドで停止してみます。
sudo systemctl stop systemd-timesyncd
そして、systemd-timesyncd を無効化します。
sudo systemctl disable systemd-timesyncd
そうしたら、以下のコマンドでシステム制御を再起動します。
sudo systemctl restart systemd-timesyncd.service
これを試しても、結局プチフリーズ解消には至りませんでした。
再度有効化するには以下のコマンドです。
sudo systemctl enable systemd-timesyncd sudo systemctl start systemd-timesyncd sudo systemctl restart systemd-timesyncd.service
そうしたら、念のためreboot して、状態確認しておいた方が良いでしょう。
systemctl status systemd-timesyncd
3-05. ufw（ファイアウォール）の原因は？
以前のこちらの記事で紹介したように、自分のラズパイ4BのVSCode SSHリモートでは、Ubuntuのファイアウォール ufw を設定して、使用可能ポートを制限していました。
この影響も考えられました。
そこで、以下のコマンドでufwを停止してみました。
sudo ufw disable
しかし、これもプチフリーズ解決には至らず、的外れでした。
４．やっと解決！ プチフリーズの原因は意外と単純
さて、このように今までいろいろと設定をこねくり回してプチフリーズの原因を探っていましたが、つい最近、ようやく原因が分かりました！！！
なかなか原因がつかめず、ほとんど諦めかけていた時に、もしやと思ってLANのスイッチングハブを外してルーターのLANポートに直挿ししてみました。
そうしたら、なんと、一発でプチフリーズが解消してしまいました。
拍子抜けです。
今まで使っていたイーサネットスイッチングハブは、７～８年前くらいに購入したと思われる比較的安価なものでした。
こう言うと、「な～んだ」となりますが、ここに至るまでが長い道のりだったんです。１か月半くらい費やしました。自分のネットワーク知識はド素人レベルなので仕方ないんですけどね。
実は、Cat5eのLANケーブルは自前で圧着して作っているのですが、その接触不良も考えられなくはないです。
しかし、同じLANケーブルを使ってルーター直挿しで正常に動作したので、今回はハブが原因と断定することにしました。
原因のハブはこれでした。
7～10年前くらいに買ったもので、当時は3,000円弱くらいのものだったと思います。
（図04-01）
DHCP lost の原因。寿命と思われるスイッチングハブ
でも、毎日電源入れっぱなしで10年弱も使っていたので、さすがに寿命だった可能性もありますね。
結局、信頼できるメーカーでそれなりに高めのスイッチに買い替えるのが正解でしょう。
でも、自分は貧乏なので、以下の物に買い換えました。
NETGEAR 卓上型コンパクト アンマネージスイッチングハブ GS308 ギガビット 8ポート 静音ファンレス 省電力設計 3年保証
実際に自分が買ったものの写真はこれです。
（図04-02）
新たに購入したスイッチングハブ。GS308
これでも個人的には痛い出費です。
4,000円弱で安価なので、もしかしたら数年後にプチフリーズが発生するかもしれません。
しかし、ネットの情報では概ね高評価で、プチフリーズも完全に無くなったので、しばらく様子を見ようと思います。
これでだめだったら高価なスイッチに買い替えるしかないですね。
でも、そこに至るまでにLinux Ubuntuのいろいろな設定方法やコマンドを知ることが出来たので個人的には収穫でしたし、LANネットワークについて少しだけ理解が深まりました。
そう言えば、以前、M5StackとM5Cameraでストリーミングしていた時、よくプチフリーズが起こっていて、これの原因を突き止めようとソースコードをいろいろこねくり回していましたが、今思えばスイッチングハブが原因だったのかも知れません…。
５．まとめ
今回の教訓は、LAN関連の通信でトラブルになったら、ソフト側だけでなくハード側も等しく疑えということでした。
それから、ルーターのファイアウォール等の設定を再確認せよということですね。
いろいろと遠回りしてしまいましたが、Linuxのネットワーク設定等、個人的に良い勉強になりましたね。
今回はここまでです。
ではまた・・・。
コメント