1

I had a problem with running edgeAgent on Azure IoT edge. It always failed. I am using:

PRETTY_NAME="Raspbian GNU/Linux 11 (bullseye)"
NAME="Raspbian GNU/Linux"|
VERSION_ID="11"
VERSION="11 (bullseye)"
VERSION_CODENAME=bullseye
ID=raspbian
ID_LIKE=debian

I tried different methods of solving this problem using Azure Microsoft tutorials and documentation: sudo apt upgrade, sudo apt update, etc.

Further, I decided to uninstall IoT edge to re-provision everything. However, the edgeHub didn't run, meanwhile edgeAgent was running well. I used this: Create and provision

Then I followed this tutorial and ended up stopping and recreating all containers. And again, I ended up with no running edgeHub, meanwhile edgeAgent is running. There is even no docker container for the edgeHub which image is supposed to be mcr.microsoft.com/azureiotedge-hub:1.4

Is there other way to have edgeHub running?

The logs from sudo iotedge check:

Configuration checks (aziot-identity-service)
---------------------------------------------
√ keyd configuration is well-formed - OK
√ certd configuration is well-formed - OK
√ tpmd configuration is well-formed - OK
√ identityd configuration is well-formed - OK
√ daemon configurations up-to-date with config.toml - OK
√ identityd config toml file specifies a valid hostname - OK
√ aziot-identity-service package is up-to-date - OK
√ host time is close to reference time - OK
√ preloaded certificates are valid - OK
√ keyd is running - OK
√ certd is running - OK
√ identityd is running - OK
√ read all preloaded certificates from the Certificates Service - OK
√ read all preloaded key pairs from the Keys Service - OK
√ check all EST server URLs utilize HTTPS - OK
√ ensure all preloaded certificates match preloaded private keys with the same ID - OK

Connectivity checks (aziot-identity-service)
--------------------------------------------
√ host can connect to and perform TLS handshake with iothub AMQP port - OK
√ host can connect to and perform TLS handshake with iothub HTTPS / WebSockets port - OK
√ host can connect to and perform TLS handshake with iothub MQTT port - OK

Configuration checks
--------------------
√ aziot-edged configuration is well-formed - OK
√ configuration up-to-date with config.toml - OK
√ container engine is installed and functional - OK
√ configuration has correct URIs for daemon mgmt endpoint - OK
√ aziot-edge package is up-to-date - OK
√ container time is close to host time - OK
‼ DNS server - Warning
    Container engine is not configured with DNS server setting, which may impact connectivity to IoT Hub.
    Please see https://aka.ms/iotedge-prod-checklist-dns for best practices.
    You can ignore this warning if you are setting DNS server per module in the Edge deployment.
‼ production readiness: logs policy - Warning
    Container engine is not configured to rotate module logs which may cause it run out of disk space.
    Please see https://aka.ms/iotedge-prod-checklist-logs for best practices.
    You can ignore this warning if you are setting log policy per module in the Edge deployment.
‼ production readiness: Edge Agent's storage directory is persisted on the host filesystem - Warning
    The edgeAgent module is not configured to persist its /tmp/edgeAgent directory on the host filesystem.
    Data might be lost if the module is deleted or updated.
    Please see https://aka.ms/iotedge-storage-host for best practices.
× production readiness: Edge Hub's storage directory is persisted on the host filesystem - Error
    Could not check current state of edgeHub container
√ Agent image is valid and can be pulled from upstream - OK
√ proxy settings are consistent in aziot-edged, aziot-identityd, moby daemon and config.toml - OK

Connectivity checks
-------------------
× container on the default network can connect to upstream AMQP port - Error
    Container on the default network could not connect to dc-hub-rnd.azure-devices.net:5671
× container on the default network can connect to upstream HTTPS / WebSockets port - Error
    Container on the default network could not connect to dc-hub-rnd.azure-devices.net:443
× container on the IoT Edge module network can connect to upstream AMQP port - Error
    Container on the azure-iot-edge network could not connect to dc-hub-rnd.azure-devices.net:5671
× container on the IoT Edge module network can connect to upstream HTTPS / WebSockets port - Error
    Container on the azure-iot-edge network could not connect to dc-hub-rnd.azure-devices.net:443
27 check(s) succeeded.
3 check(s) raised warnings. Re-run with --verbose for more details.
5 check(s) raised errors. Re-run with --verbose for more details.
2 check(s) were skipped due to errors from other checks. Re-run with --verbose for more details.
  • I would be more concerned about the fact that the iotedge check could not connect to your IoT hub. If it can't talk to the hub then it won't get the device twin with the manifest thus no other containers will be run. "Container on the default network could not connect to dc-hub-rnd.azure-devices.net:5671" – Mark Radbourne Feb 25 '23 at 21:33

1 Answers1

0

The edgeHub will only run if you specify modules other than edgeAgent and edgeHub in your deployment manifest. A newly provisioned device will not have an edgeHub running. It can also explain why sudo iotedge check will show you an error about production readiness. It's a note in this section of the documentation.

When you add a new module to the manifest, the hub should start running.

Matthijs van der Veer
  • 3,865
  • 2
  • 12
  • 22
  • Hi, thanks, I have already deployed the modules on Azure Portal as it is instructed. I read this comment you provided. but the device reports no value. The logs show connectivity errors listed in Connectivity Checks. – Arseniy Sleptsov Feb 02 '23 at 08:50
  • 1
    Okay, thanks for the information. Can you try [setting the DNS](https://learn.microsoft.com/en-us/azure/iot-edge/troubleshoot-common-errors?WT.mc_id=IoT-MVP-5004034&view=iotedge-1.4#solution-2) for the container engine? From your logs, the host can do a TLS handshake with the IoT Hub, but the container can't connect. Setting the DNS manually could help. – Matthijs van der Veer Feb 02 '23 at 09:26
  • Ok, it worked now. Thanks. Why do you think it sometimes works without setting up dns? – Arseniy Sleptsov Feb 02 '23 at 10:03
  • Honestly, I'm not sure. I've learned through experience that many issues are caused by DNS-related things. The network you're on might have its own DNS, or the runtime uses a different one than you expect. Forcing it to a known DNS can resolve these issues. I'm glad you have the device running again! – Matthijs van der Veer Feb 02 '23 at 12:20