Lösningar på vanliga problem för Azure IoT Edge

gäller för: IoT Edge 1.1

Använd den här artikeln för att identifiera och lösa vanliga problem när du använder IoT Edge-lösningar. Om du behöver information om hur du hittar loggar och fel från din IoT Edge-enhet kan du läsa Felsöka din IoT Edge-enhet.

Etablering och distribution

IoT Edge-modulen distribueras framgångsrikt och försvinner sedan från enheten

Symptomer

När du har angett moduler för en IoT Edge-enhet distribueras modulerna, men efter några minuter försvinner de från enheten och från enhetsinformationen i Azure Portal. Andra moduler än de som definierats kan också visas på enheten.

Orsak

Om en automatisk distribution riktar sig mot en enhet prioriteras den framför att manuellt ange modulerna för en enskild enhet. Funktionen Set modules i Azure portal eller Create deployment for single device funktionalitet i Visual Studio Code träder i kraft omedelbart. Du ser de moduler som du definierade startar på enheten. Sedan startar den automatiska distributionen och prioriteringen skriver över enhetens önskade egenskaper.

Lösning

Använd endast en typ av distributionsmekanism per enhet, antingen en automatisk distribution eller enskilda enhetsdistributioner. Om du har flera automatiska distributioner riktade till en enhet kan du ändra prioritets- eller målbeskrivningar för att se till att rätt distribution gäller för en viss enhet. Du kan också uppdatera enhetstvillingen så att den inte längre matchar målbeskrivningen för den automatiska distributionen.

Mer information finns i Förstå automatiska IoT Edge-distributioner för enskilda enheter eller i stor skala.

Det går inte att hämta IoT Edge-körningsloggarna i Windows

Symptomer

Du får en EventLogException när du använder Get-WinEvent i Windows.

Orsak

Get-WinEvent PowerShell-kommandot förlitar sig på att en registerpost finns för att hitta loggar av en specifik ProviderName.

Lösning

Ange en registerpost för IoT Edge-daemonen. Skapa en iotedge.reg fil med följande innehåll och importera till Windows-registret genom att dubbelklicka på den eller med kommandot reg import iotedge.reg :

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog\Application\iotedged]
"CustomSource"=dword:00000001
"EventMessageFile"="C:\\ProgramData\\iotedge\\iotedged.exe"
"TypesSupported"=dword:00000007

DPS-klientfel

Symptomer

Det går inte att starta IoT Edge med felmeddelandet failed to provision with IoT Hub, and no valid device backup was found dps client error.

Orsak

En gruppregistrering används för att ansluta en IoT Edge-enhet för en IoT Hub. IoT Edge-enheten flyttas till en annan hubb. Registreringen tas bort i DPS. En ny registrering skapas i DPS för den nya hubben. Enheten har inte återkonfigurerats.

Lösning

1. Kontrollera att dina DPS-autentiseringsuppgifter är korrekta.
2. Använd din konfiguration med sudo iotedge apply config.
3. Om enheten inte har återförsörjts startar du om enheten med sudo iotedge system restart.
4. Om enheten inte har ometablerats, tvinga fram ometablering med hjälp av sudo iotedge system reprovision.

Om du vill återskapa automatiskt anger du dynamic_reprovisioning: true i enhetskonfigurationsfilen. Genom att sätta denna flagga till true aktiverar du funktionen för dynamisk återetablering. IoT Edge identifierar situationer där enheten verkar ha återskapats i molnet genom att övervaka sin egen IoT Hub-anslutning för vissa fel. IoT Edge svarar genom att stänga av alla Edge-moduler och sig själv. Nästa gång daemonen startas försöker den återskapa den här enheten med Azure för att ta emot den nya IoT Hub-etableringsinformationen.

När du använder extern etablering meddelar daemon även den externa etableringsslutpunkten om ometableringshändelsen innan den stängs av. För mer information, se IoT Hub-enheters omdisponeringskoncept.

IoT Edge-körtidsmiljö

IoT Edge-agenten stoppas efter en minut

Symptomer

EdgeAgent-modulen startar och körs i ungefär en minut och stoppas sedan. Loggarna anger att IoT Edge-agenten försöker ansluta till IoT Hub via AMQP och sedan försöker ansluta med AMQP via WebSocket. När det misslyckas avslutas IoT Edge-agenten.

Exempel på edgeAgent-loggar:

2017-11-28 18:46:19 [INF] - Starting module management agent.
2017-11-28 18:46:19 [INF] - Version - 1.0.7516610 (03c94f85d0833a861a43c669842f0817924911d5)
2017-11-28 18:46:19 [INF] - Edge agent attempting to connect to IoT Hub via AMQP...
2017-11-28 18:46:49 [INF] - Edge agent attempting to connect to IoT Hub via AMQP over WebSocket...

Orsak

En nätverkskonfiguration i värdnätverket hindrar IoT Edge-agenten från att nå nätverket. Agenten försöker ansluta via AMQP (port 5671) först. Om anslutningen misslyckas försöker den använda WebSockets (port 443).

IoT Edge-körningen ställer in ett nätverk för varje modul att kommunicera på. På Linux är nätverket en nätverksbrygga. I Windows använder den NAT. Det här problemet är vanligare på Windows-enheter som använder Windows-containrar som använder NAT-nätverket.

Lösning

Se till att det finns en väg till Internet för IP-adresserna som tilldelats till den här bryggan/NAT-nätverket. Ibland åsidosätter en VPN-konfiguration på värden IoT Edge-nätverket.

Edge-agentmodulen rapporterar "tom konfigurationsfil", och inga moduler startar på enheten

Symptomer

Enheten har problem med att starta moduler som definierats i distributionen. Endast edgeAgent körs och rapporterar kontinuerligt "tom konfigurationsfil...".

Orsak

Som standard startar IoT Edge moduler i sitt eget isolerade containernätverk. Enheten kan ha problem med DNS-namnmatchning i det här privata nätverket.

Lösning

Alternativ 1: Ange DNS-server i inställningar för containermotorn

Ange DNS-servern för din miljö i inställningarna för containermotorn, som gäller för alla containermoduler som startas av motorn. Skapa en fil med namnet daemon.jsonoch ange sedan den DNS-server som ska användas. Till exempel:

{
    "dns": ["1.1.1.1"]
}

Den här DNS-servern är inställd på en offentligt tillgänglig DNS-tjänst. Men vissa nätverk, till exempel företagsnätverk, har sina egna DNS-servrar installerade och tillåter inte åtkomst till offentliga DNS-servrar. Om gränsenheten därför inte kan komma åt en offentlig DNS-server ersätter du den med en tillgänglig DNS-serveradress.

Placera daemon.json på rätt plats för din plattform:

Om platsen redan innehåller daemon.json filen lägger du till dns-nyckeln i den och sparar filen.

Starta om containermotorn så att uppdateringarna börjar gälla.

Alternativ 2: Ange DNS-server i IoT Edge-distributionen för varje modul

Du kan ange DNS-server för varje moduls createOptions i IoT Edge-distributionen. Till exempel:

"createOptions": {
  "HostConfig": {
    "Dns": [
      "x.x.x.x"
    ]
  }
}

Se till att ange den här konfigurationen även för edgeAgent - och edgeHub-modulerna .

IoT Edge-agenten kan inte få åtkomst till en moduls avbildning (403)

Symptomer

Det går inte att köra en container och edgeAgent-loggarna rapporterar ett 403-fel.

Orsak

IoT Edge-agentmodulen har inte behörighet att komma åt en moduls avbildning.

Lösning

Se till att dina autentiseringsuppgifter för containerregistret är korrekta i ditt enhetsdistributionsmanifest.

IoT Edge-hubb startar inte

Symptomer

Det går inte att starta edgeHub-modulen. Du kan se ett meddelande som något av följande fel i loggarna:

One or more errors occurred.
(Docker API responded with status code=InternalServerError, response=
{\"message\":\"driver failed programming external connectivity on endpoint edgeHub (6a82e5e994bab5187939049684fb64efe07606d2bb8a4cc5655b2a9bad5f8c80):
Error starting userland proxy: Bind for 0.0.0.0:443 failed: port is already allocated\"}\n)

Eller

info: edgelet_docker::runtime -- Starting module edgeHub...
warn: edgelet_utils::logging -- Could not start module edgeHub
warn: edgelet_utils::logging --     caused by: failed to create endpoint edgeHub on network nat: hnsCall failed in Win32:  
        The process cannot access the file because it is being used by another process. (0x20)

Orsak

En annan process på värddatorn har bundit en port som edgeHub-modulen försöker binda. IoT Edge-hubben mappar portarna 443, 5671 och 8883 för användning i gatewayscenarier. Det går inte att starta modulen om en annan process redan har bundit en av dessa portar.

Lösning

Du kan lösa det här problemet på två sätt:

Om IoT Edge-enheten fungerar som en gatewayenhet måste du hitta och stoppa processen som använder port 443, 5671 eller 8883. Ett fel för port 443 innebär vanligtvis att den andra processen är en webbserver.

Om du inte behöver använda IoT Edge-enheten som en gateway kan du ta bort portbindningarna från edgeHubs modulskapandealternativ. Du kan ändra skapandealternativen i Azure Portal eller direkt i deployment.json-filen.

På Azure-portalen:

1. Gå till din IoT-hubb och välj Enheter under menyn Enhetshantering .

2. Välj den IoT Edge-enhet som du vill uppdatera.

3. Välj Ange moduler.

4. Välj Körningsinställningar.

5. I inställningarna för Edge Hub-modulen tar du bort allt från textrutan Skapa alternativ .

6. Spara ändringarna och skapa distributionen.

I filen deployment.json:

1. Öppna den deployment.json fil som du har tillämpat på din IoT Edge-enhet.

2. edgeHub Hitta inställningarna i avsnittet önskade egenskaper för edgeAgent:

   "edgeHub": {
       "settings": {
           "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
           "createOptions": "{\"HostConfig\":{\"PortBindings\":{\"8883/tcp\":[{\"HostPort\":\"8883\"}],\"443/tcp\":[{\"HostPort\":\"443\"}]}}}"
       },
       "type": "docker",
       "status": "running",
       "restartPolicy": "always"
   }
   

3. Ta bort linjen createOptions och det avslutande kommatecknet i slutet av image raden före den:

   "edgeHub": {
       "settings": {
           "image": "mcr.microsoft.com/azureiotedge-hub:1.1"
       },
       "type": "docker",
       "status": "running",
       "restartPolicy": "always"
   }
   

4. Spara filen och tillämpa den på din IoT Edge-enhet igen.

IoT Edge-modulen misslyckas med att skicka ett meddelande till edgeHub och får 404-fel

Symptomer

En anpassad IoT Edge-modul kan inte skicka ett meddelande till IoT Edge-hubben med ett 404-fel Module not found . IoT Edge-runtime skriver ut följande meddelande till loggfilerna:

Error: Time:Thu Jun  4 19:44:58 2018 File:/usr/sdk/src/c/provisioning_client/adapters/hsm_client_http_edge.c Func:on_edge_hsm_http_recv Line:364 executing HTTP request fails, status=404, response_buffer={"message":"Module not found"}u, 04 )

Orsak

IoT Edge-körningen tillämpar processidentifiering för alla moduler som ansluter till edgeHub av säkerhetsskäl. Den verifierar att alla meddelanden som skickas av en modul kommer från modulens huvudprocess-ID. Om ett meddelande skickas av en modul från ett annat process-ID än vad som ursprungligen upprättades avvisas meddelandet med ett 404-felmeddelande.

Lösning

Från och med version 1.0.7 har alla modulprocesser behörighet att ansluta. Mer information finns i versionsändringsloggen 1.0.7.

Om du inte kan uppgradera till 1.0.7 utför du följande steg. Kontrollera att samma process-ID alltid används av den anpassade IoT Edge-modulen för att skicka meddelanden till edgeHub. Se till exempel att använda ENTRYPOINT istället för CMD kommandot i Docker-filen. Kommandot CMD leder till ett process-ID för modulen och ett annat process-ID för bash-kommandot som kör huvudprogrammet, men ENTRYPOINT leder till ett enda process-ID.

Stabilitetsproblem på mindre enheter

Symptomer

Du kan uppleva stabilitetsproblem på resursbegränsade enheter som Raspberry Pi, särskilt när de används som en gateway. Symtomen är minnesfel i IoT Edge-hubbmodulen, underordnade enheter som inte kan ansluta eller att enheten inte kan skicka telemetrimeddelanden efter några timmar.

Orsak

IoT Edge-hubben, som är en del av IoT Edge-körningen, är optimerad för prestanda som standard och försöker allokera stora mängder minne. Den här optimeringen är inte idealisk för begränsade gränsenheter och kan orsaka stabilitetsproblem.

Lösning

För IoT Edge-hubben anger du en miljövariabel OptimizeForPerformance till false. Det finns två sätt att ange miljövariabler:

På Azure-portalen:

I din IoT Hub väljer du din IoT Edge-enhet och från sidan med enhetsinformation väljer du Ange moduler>Inställningar för körning. Skapa en miljövariabel för IoT Edge-hubbmodulen med namnet OptimizeForPerformance som är inställd på false.

I distributionsmanifestet:

"edgeHub": {
  "type": "docker",
  "settings": {
    "image": "mcr.microsoft.com/azureiotedge-hub:1.1",
    "createOptions": <snipped>
  },
  "env": {
    "OptimizeForPerformance": {
      "value": "false"
    }
  },

Det gick inte att starta säkerhetsdaemonen

Symptomer

Säkerhetsdaemonen startar inte och modulcontainrar skapas inte. edgeAgent, edgeHub och andra anpassade moduler startas inte av IoT Edge-tjänsten. I aziot-edged loggar visas det här felet:

• Det gick inte att starta daemonen: Det gick inte att starta hanteringstjänsten
• orsakad av: Ett fel uppstod för sökvägen /var/run/iotedge/mgmt.sock
• orsakad av: Behörighet nekad (os-fel 13)

Orsak

För alla Linux-distributioner utom CentOS 7 är IoT Edge standardkonfiguration att använda systemd socketaktivering. Ett behörighetsfel inträffar om du ändrar konfigurationsfilen så att den inte använder socketaktivering men lämnar URL:erna som /var/run/iotedge/*.sock, eftersom iotedge-användaren inte kan skriva till /var/run/iotedge vilket innebär att den inte kan låsa upp och montera socketarna själv.

Lösning

Du behöver inte inaktivera socketaktivering på en distribution där socketaktivering stöds. Men om du föredrar att inte använda socketaktivering alls, placera socketarna i /var/lib/iotedge/.

1. Kör systemctl disable iotedge.socket iotedge.mgmt.socket för att inaktivera socketenheterna så att systemd inte startar dem i onödan
2. Ändra iotedge-konfigurationen så att den använder /var/lib/iotedge/*.sock i både connect- och listen-avsnitten.
3. Om du redan har moduler har de de gamla /var/run/iotedge/*.sock monteringarna, så ersätt docker rm -f dem.

Det gick inte att starta modulen på grund av matchningsfel i operativsystemet

Symtom

EdgeHub-modulen startar inte i IoT Edge version 1.1.

Orsak

Windows-modulen använder en version av Windows som inte är kompatibel med värdens Windows-version. IoT Edge Windows version 1809 build 17763 behövs som basskikt för modulavbildningen, men en annan version används.

Lösning

Kontrollera versionen av dina olika Windows-operativsystem i Felsöka skillnader mellan värd- och containeravbildningar. Om operativsystemen skiljer sig åt uppdaterar du dem till IoT Edge Windows version 1809 build 17763 och återskapar Docker-avbildningen som används för modulen.

Nätverkande

IoT Edge-säkerhetsdaemon misslyckas med ett ogiltigt värddatornamn

Symptomer

Försök att kontrollera IoT Edge-säkerhetshanterarens loggar misslyckas och skriver ut följande meddelande:

Error parsing user input data: invalid hostname. Hostname cannot be empty or greater than 64 characters

Orsak

IoT Edge-körningen kan bara stödja värdnamn som är kortare än 64 tecken. Fysiska datorer har vanligtvis inte långa värdnamn, men problemet är vanligare på en virtuell dator. De automatiskt genererade värdnamnen för virtuella Windows-datorer som finns i Azure, i synnerhet, tenderar att vara långa.

Lösning

När du ser det här felet kan du lösa det genom att konfigurera DNS-namnet på den virtuella datorn och sedan ange DNS-namnet som värdnamn i installationskommandot.

1. I Azure Portal navigerar du till översiktssidan för den virtuella datorn.

2. Välj konfigurera under DNS-namn. Om den virtuella datorn redan har konfigurerat ett DNS-namn behöver du inte konfigurera ett nytt.

   

3. Ange ett värde för DNS-namnetiketten och välj Spara.

4. Kopiera det nya DNS-namnet, som ska ha formatet <DNSnamelabel>.<vmlocation.cloudapp.azure.com>.

5. I den virtuella datorn använder du följande kommando för att konfigurera IoT Edge-körningen med ditt DNS-namn:

   • På Linux:

     sudo nano /etc/iotedge/config.yaml
     

   • På Windows:

     notepad C:\ProgramData\iotedge\config.yaml
     

IoT Edge-modulen rapporterar anslutningsfel

Symptomer

IoT Edge-moduler som ansluter direkt till molntjänster, inklusive runtime-moduler, slutar fungera som förväntat och returnerar fel kring anslutnings- eller nätverksfel.

Orsak

Containrar förlitar sig på vidarebefordran av IP-paket för att kunna ansluta till Internet så att de kan kommunicera med molntjänster. Vidarebefordran av IP-paket är aktiverat som standard i Docker, men om det inaktiveras fungerar inte moduler som ansluter till molntjänster som förväntat. Mer information finns i Förstå containerkommunikation i Docker-dokumentationen.

Lösning

Använd följande steg för att aktivera vidarebefordran av IP-paket.

På Windows:

1. Öppna programmet Kör .

2. Ange regedit i textrutan och välj Ok.

3. I fönstret Registereditorn bläddrar du till HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters.

4. Leta efter parametern IPEnableRouter .

   1. Om parametern finns anger du värdet för parametern till 1.

   2. Om parametern inte finns lägger du till den som en ny parameter med följande inställningar:

      Inställning	Värde
      Namn	IPEnableRouter
      Typ	REG_DWORD
      Värde	1

5. Stäng registerredigerarens fönster.

6. Starta om systemet för att tillämpa ändringarna.

På Linux:

1. Öppna filen sysctl.conf.

   sudo nano /etc/sysctl.conf
   

2. Lägg till följande rad i filen.

   net.ipv4.ip_forward=1
   

3. Spara och stäng filen.

4. Starta om nätverkstjänsten och Docker-tjänsten för att tillämpa ändringarna.

Nästa steg

Tror du att du har hittat ett fel i IoT Edge-plattformen? Skicka in ett problem så att vi kan fortsätta att förbättra.

Om du har fler frågor skapar du en supportbegäran om hjälp.