Armadilloフォーラム

Linux9対応でのAzure IoT送信時のエラー

kishikawa_kit

2019年6月22日 19時52分

お世話になります。
「cfsetspeedの暗黙の宣言」の投稿と同じ者です。

繰り返しになりますが、Armadillo-IoT G3用(Linux8)に、電力量計からRS485通信で取得したデータをC用のAzure IoT device SDKを利用してAzure IoTへ送信するシステムを構築し、このたびLinux9に対応する必要が出てきました。

24時間監視で10分ごとに計測したデータをAzure IoTへ送信していますが、何時間か経つと以下のエラーが発生します。
何時間後かはそのときでまちまちですが、24時間持つことはありません。

Linux8の時は連続24時間監視が出来ておりました。
エラー内容にOpenSSL関連のものがありますが、ライブラリはOpenSSL1.1.0jが入っております。

気になる点として、Azure SDKは2017年のものを使用しておりますが、Linux9はAzure SDKが最新のものでないと正常に動作しないと言ったことも考えられますでしょうか?

原因についてご教示いただけますと幸いです。

Info: IoT Hub SDK for C, version 1.1.22
IoTHubClient_LL_SetMessageCallback...successful.
Error: Time:Tue Jun 18 03:00:02 2019 File:/home/atmark/work/IoT_SDK/azure-iot-sdk-c/c-utility/adapters/socketio_berkeley.c Func:socketio_open Line:626 Failure: getaddrinfo failure -3.
Info: Closing tlsio from a state other than TLSIO_STATE_EXT_OPEN or TLSIO_STATE_EXT_ERROR
Error: Time:Tue Jun 18 03:00:02 2019 File:/home/atmark/work/IoT_SDK/azure-iot-sdk-c/c-utility/src/tlsio_openssl.c Func:on_underlying_io_open_complete Line:688 Invalid tlsio_state. Expected state is TLSIO_STATE_OPENING_UNDERLYING_IO.
Error: Time:Tue Jun 18 03:00:02 2019 File:/home/atmark/work/IoT_SDK/azure-iot-sdk-c/c-utility/src/tlsio_openssl.c Func:tlsio_openssl_open Line:1202 Failed opening the underlying I/O.
Error: Time:Tue Jun 18 03:00:02 2019 File:/home/atmark/work/IoT_SDK/azure-iot-sdk-c/umqtt/src/mqtt_client.c Func:mqtt_client_connect Line:971 Error: io_open failed
Error: Time:Tue Jun 18 03:00:02 2019 File:/home/atmark/work/IoT_SDK/azure-iot-sdk-c/iothub_client/src/iothubtransport_mqtt_common.c Func:SendMqttConnectMsg Line:1661 failure connecting to address IoTHubArmdl001.azure-devices.net.
コメント

中村です。

Failure: getaddrinfo failure -3.
を調べてみました。

getaddrinfo のエラーコード3はEAI_AGAINで、
EAI_AGAINは、
「ネームサーバーから一時的な失敗(temporary failure)を
意味する返 事が返された。後でもう一度試してみよ。」
と、getaddrinfoのmanページに記載がありました。

このエラーが発生したときに、ネットワークのエラーなどが
発生していないか、syslogなどのログを調べてみると、
何か手がかりが得られるかもしれません。

--
なかむら

中村様

回答ありがとうございます。

なるほど。ネームサーバーとはこの場合送信先のAzure IoT Hubになるのでしょうね。
あまり考えられませんが別の何かが同じHubに送信しているとかで、処理がぶつかっているとか?

syslogを調べてみましたが、ネットワーク系のエラーなど手掛かりのようなものは見つけられませんでした。

ただ、「cfsetspeedの暗黙の宣言」の方で頂いた方法を行ったところ、このエラーの発生はなくなりました。
テストを継続して、様子を見たいと思います。

ありがとうございました。