ta-imai
2025年5月1日 16時18分
==========
製品型番：AG6271-C03Z
Debian/ABOSバージョン：3.19.1-at.1
カーネルバージョン：5.10.210-0-at
3G/LTE モジュール情報 (Debianのみ)：
その他：
==========
現場に設置した機器でLTE切断後、LTEに再接続が行われませんでした。
LTE再接続サービスも起動していますが、LTEモジュールの再起動も実行されていないように見えます。
同じ現場に設置したもう一台は、同時刻にLTE切断しましたがその後再接続できていました。
/var/log/message, /etc/atmark/connection-recover.conf,/etc/atmark/els31.conf を添付します
(LTEの切断は 2025/03/18 22:02頃です)。
再接続できない原因、対策等ありますでしょうか。
| ファイル | ファイルの説明 |
|---|---|
| messages.zip |
コメント
ta-imai
at_makoto.sato
ありがとうございます。
> /var/log/connection-recover.log は作成されていませんでした。
承知しました。お使いになられているabosのバージョンでは、
connection-recover.logにログを出力する対応を入れる前のバージョンでした。
また可能であれば、最新のABOSのバージョンにアップデートして再現確認をお願いします。
ただ、messages の方にもほとんど connection-recover のログが出ていないのが気になります。
今一度確認させてください。以下のコマンド実行結果はどうなっていますでしょうか。
armadillo:~# rc-status | grep connection-recover armadillo:~# nmcli c armadillo:~# cat /etc/atmark/connection-recover.conf
また、可能であれば最新のバージョンのABOSにアップデートして再現するか確認をお願いできますでしょうか。
ta-imai
ご回答ありがとうございます。
> 今一度確認させてください。以下のコマンド実行結果はどうなっていますでしょうか。
現場の機器は確認できないのですが、
同じインストールイメージから作成している機器では下記のようになっています。
armadillo:~# rc-status | grep connection-recover connection-recover [ started ] armadillo:~# nmcli c NAME UUID TYPE DEVICE gsm-ttyCommModem 4e8aae2f-ea90-46d1-85e1-895b227364fa gsm ttyCommModem lo 7e39ec38-5fab-4a4a-a659-dce18a832568 loopback lo podman0 8919f667-ae41-4b65-a067-4f112325f1fd bridge podman0 abos_web_br_ap 6aeab875-8235-47bf-b7e7-61cdf6666b7c bridge br_ap veth0 2866bb38-f670-400b-ae8f-81ff7b2446ca ethernet veth0 Wired connection 1 0d60d547-9489-38cc-a278-f935b96b953b ethernet -- Wired connection 2 abd93784-2f0e-3e44-9818-b22988c0bc21 ethernet -- armadillo:~# cat /etc/atmark/connection-recover.conf #!/bin/sh # SPDX-License-Identifier: MIT CHECK_INTERVAL_SEC=60 PING_DEST_IP=8.8.8.8 FORCE_REBOOT=FALSE REBOOT_IF_SIM_NOT_FOUND=TRUE WWAN_FORCE_RESTART_COUNT=3 armadillo:~#
> また、可能であれば最新のバージョンのABOSにアップデートして再現するか確認をお願いできますでしょうか。
ABOSのアップデートを検討します。
以上、よろしくお願いします。
at_makoto.sato
ta-imai
お世話になっております。
別の現場で nmcli c を実行した際に、応答がない場合がありました。
CTRL+Cで止めるまで30秒くらいです。
/var/log/messagesを添付します。
原因は何が考えられますでしょうか。
nmcliを実行したのは 6/25 15:00頃です。
armadillo:~# rc-status | grep connection-recover connection-recover [ started ] armadillo:~# nmcli c ^CError: nmcli terminated by signal Interrupt (2) armadillo:~# armadillo:~# nmcli c
connection-recover内ではnmcli実行していますが、
nmcli の応答がない場合は connection-recover も応答待ちで止まってしまいますか。
以上、よろしくお願いします。
| ファイル | ファイルの説明 |
|---|---|
| messages.zip |
at_makoto.sato
佐藤です
> 別の現場で nmcli c を実行した際に、応答がない場合がありました。
> CTRL+Cで止めるまで30秒くらいです。
CTRL+C で止めたあとに再度 nmcli c をすると正常でしたでしょうか？
> /var/log/messagesを添付します。
> 原因は何が考えられますでしょうか。
> nmcliを実行したのは 6/25 15:00頃です。
ログの6/25 15:00頃には手がかりになりそうなログはありませんでした。
> connection-recover内ではnmcli実行していますが、
> nmcli の応答がない場合は connection-recover も応答待ちで止まってしまいますか。
原因が分からないと確定的なことは言えませんが、その可能性は高いと思います。
ta-imai
お世話になります。
手元の機器でconnection-recoverがnmcliの実行で止まってしまう現象が起きました。
添付のrssi_check.shでLTEの電波強度をログするスクリプトのみ動かした状態です。
他に確認した方が良いところありますでしょうか。
armadillo:~# rc-status | grep connection-recover
connection-recover [ started ]
armadillo:~# nnmcli c
NAME UUID TYPE DEVICE
gsm-ttyCommModem 4e8aae2f-ea90-46d1-85e1-895b227364fa gsm ttyCommModem
lo 69cc6851-c9f4-430d-9e3e-f30649219720 loopback lo
podman0 f2e99cfe-1d32-4eee-8109-e895d7715fa9 bridge podman0
abos_web_br_ap 6aeab875-8235-47bf-b7e7-61cdf6666b7c bridge br_ap
veth0 f0ba6c4a-3b1d-4c13-add0-50a33bcdffee ethernet veth0
Wired connection 1 0d60d547-9489-38cc-a278-f935b96b953b ethernet --
Wired connection 2 d8fc2a3d-b42c-3fb4-80c7-91089d15fa5a ethernet --
armadillo:~# cat /etc/atmark/connection-recover.conf
#!/bin/sh
# SPDX-License-Identifier: MIT
CHECK_INTERVAL_SEC=60
PING_DEST_IP=8.8.8.8
FORCE_REBOOT=FALSE
REBOOT_IF_SIM_NOT_FOUND=TRUE
WWAN_FORCE_RESTART_COUNT=3
armadillo:~# pstree -p && sleep 10 && pstree -p
init(1)-+-aardvark-dns(1734)-+-{aardvark-dns}(1736)
| |-{aardvark-dns}(1737)
| `-{tokio-runtime-w}(1738)
|-abos-web(1643)---{tokio-runtime-w}(1652)
|-avahi-daemon(1512)---avahi-daemon(1519)
|-buttond(1198)
|-chronyd(1544)
|-conmon(1741)---reboot_server.s(1743)
|-connection-reco(1309)-+-grep(1370)
| |-nmcli(1368)-+-{gdbus}(1374)
| | |-{gmain}(1371)
| | `-{pool-spawner}(1372)
| `-sed(1369)
|-dbus-daemon(950)
|-dnsmasq(1070)
|-getty(1812)
|-getty(1813)
|-getty(1815)
|-getty(1816)
|-getty(1817)
|-getty(1818)
|-klogd(996)
|-login(12274)---ash(19908)---pstree(23447)
|-power-utils(1499)
|-rssi_check.sh(1794)---sleep(23381)
|-sshd(1624)
|-supervise-daemo(1004)---ModemManager(1006)-+-{gdbus}(1036)
| |-{gmain}(1025)
| `-{pool-spawner}(1029)
|-supervise-daemo(1038)---NetworkManager(1040)-+-{gdbus}(1067)
| |-{gmain}(1063)
| `-{pool-spawner}(1065)
|-supervise-daemo(1295)---armadillo-twin-(1299)---{AwsEventLoop 1}(1668)
|-supervise-daemo(1489)---hostapd(1493)
|-syslogd(946)
|-udevd(501)
`-wwan-led(1201)---sleep(23444)
init(1)-+-aardvark-dns(1734)-+-{aardvark-dns}(1736)
| |-{aardvark-dns}(1737)
| `-{tokio-runtime-w}(1738)
|-abos-web(1643)---{tokio-runtime-w}(1652)
|-avahi-daemon(1512)---avahi-daemon(1519)
|-buttond(1198)
|-chronyd(1544)
|-conmon(1741)---reboot_server.s(1743)
|-connection-reco(1309)-+-grep(1370)
| |-nmcli(1368)-+-{gdbus}(1374)
| | |-{gmain}(1371)
| | `-{pool-spawner}(1372)
| `-sed(1369)
|-dbus-daemon(950)
|-dnsmasq(1070)
|-getty(1812)
|-getty(1813)
|-getty(1815)
|-getty(1816)
|-getty(1817)
|-getty(1818)
|-klogd(996)
|-login(12274)---ash(19908)---pstree(23473)
|-power-utils(1499)
|-rssi_check.sh(1794)---sleep(23463)
|-sshd(1624)
|-supervise-daemo(1004)---ModemManager(1006)-+-{gdbus}(1036)
| |-{gmain}(1025)
| `-{pool-spawner}(1029)
|-supervise-daemo(1038)---NetworkManager(1040)-+-{gdbus}(1067)
| |-{gmain}(1063)
| `-{pool-spawner}(1065)
|-supervise-daemo(1295)---armadillo-twin-(1299)---{AwsEventLoop 1}(1668)
|-supervise-daemo(1489)---hostapd(1493)
|-syslogd(946)
|-udevd(501)
`-wwan-led(1201)---sleep(23470)
armadillo:~# ps |grep nmcli && sleep 10 && ps | grep nmcli
1368 root 0:00 nmcli -f NAME connection
23540 root 0:00 grep nmcli
1368 root 0:00 nmcli -f NAME connection
23567 root 0:00 grep nmcli
armadillo:~# ps -o pid,user,time,comm,etime |grep nmcli
1368 root 0:00 nmcli 1d06| ファイル | ファイルの説明 |
|---|---|
| 20250702.zip |
at_makoto.sato
ta-imai
at_makoto.sato
佐藤です。
> nmcli c は正常に実行できています。
connection-recover が nmcli で止まっている最中でも
コンソールから "nmcli c" の実行が可能ということですので、
dbusが詰まっていたりNetworkManagerがフリーズしているということは無さそうです。
connection-recover内のnmcliのリクエストが何らかの理由でdropしてしまったのかもしれません。
根本解決にはなっていないのですが、回避策として
connection-recoverの以下の箇所を
active_connection_exists() {
if nmcli -f NAME connection | sed -e 's/ *$//' | grep -x -q "${CONNECTION}"; then
return 0
fi
return 1
}以下のようにすると、5秒応答ないときはタイムアウトするようになり、ここで止まりっぱなしになるということはなくなると思います。
active_connection_exists() {
if timeout -sKILL 5s nmcli -f NAME connection | sed -e 's/ *$//' | grep -x -q "${CONNECTION}"; then
return 0
fi
return 1
}ta-imai
at_makoto.sato
2025年5月1日 18時04分
佐藤です。
すいません。
現象発生時の connection-recover のログもいただけますでしょうか。
/var/log/connection-recover.log
/var/log/connection-recover.log.0 (こちらはあれば)