Status & Doctor
ironflock status zeigt, was von IronFlock auf einer Maschine vorhanden ist und ob es läuft. ironflock doctor prüft, ob eine Maschine den Geräte-Agenten ausführen kann und ob sie die Hosts erreicht, mit denen der Agent spricht. Verwenden Sie die beiden, bevor Sie eine Maschine verbinden und wenn ein Gerät nicht online kommt.
Beide Befehle ändern nichts und fragen nichts. Sie laufen unter Linux und macOS, ohne Root-Rechte, und lesen als root mehr. Mit --host laufen sie auf einer anderen Maschine, auch auf mehreren gleichzeitig (Entfernte Maschinen über SSH). Dort laufen sie als root, wenn der SSH-Benutzer root ist oder sudo ohne Passwort und ohne Terminal verwenden darf; andernfalls laufen sie als SSH-Benutzer, ohne zu fragen, und ihr Hinweis nennt den Befehl mit --host root@machine.
ironflock status
Zeigt den Geräte-Agenten, die Appliance und das Betriebssystem dieser Maschine: was installiert ist, seine Version, ob sein Dienst läuft, das Gerät und sein Projekt und das letzte Selbst-Update des Agenten. Die Appliance ist das vollständige IronFlock-System auf einer Maschine vor Ort (IronFlock Appliance); für eine Appliance zeigt der Befehl außerdem die Adresse ihrer Oberfläche, ihre Lizenz, den Zustand ihrer Dienste und ein wartendes Update (Befehle für die Appliance). Unter IronFlockOS zeigt der Befehl außerdem die Root-Slots und was Aufmerksamkeit braucht.
ironflock status [flags]Läuft unter: Linux; unter macOS zeigt er das System und dass nichts installiert ist. Root-Rechte: nicht nötig; einige Angaben brauchen sie. Fragt: nichts.
Der Befehl hat keine eigenen Flags. Er akzeptiert die globalen Flags (Globale Flags).
Ohne Root-Rechte lassen sich einige Angaben nicht lesen: das Gerät und sein Projekt, da die .flock des Agenten allein root gehört, und auf einer Appliance, deren Ordner /opt/ironflock root gehört, auch die Versionen, die URL der Appliance, ihre Lizenz und ihr Update sowie das Update des Agenten. Der Zustand der Dienste der Appliance braucht Root-Rechte oder die Gruppe docker. Sie lauten unknown (needs root), das JSON-Feld needs_root listet sie auf, und sudo ironflock status liest sie.
# Was auf dieser Maschine ist, gelesen mit Ihrem Benutzer
ironflock status
# Alles, als JSON
sudo ironflock status --json
# Der Status einer anderen Maschine über SSH
ironflock --host pi@device-17 statusTextausgabe
$ ironflock status
Agent: installed in /opt/ironflock/device-agent
Version: 1.6.9
Service: running (ironflock-device-agent.service)
Connection: unknown (this agent does not report it)
Device: unknown (needs root)
Swarm: unknown (needs root)
Update: none pending
Appliance: not installed
System: Debian GNU/Linux 12 (bookworm)
Run 'sudo ironflock status' to read what needs root.Swarm ist das Projekt des Geräts. Connection ist unknown bei einem laufenden Agenten: Die bisher veröffentlichten Agenten melden ihre Verbindung auf der Maschine nicht.
Unter IronFlockOS
Die Systemzeile zeigt das Image und seine zwei Root-Slots (Root-Slots und die Datenpartition):
System: IronFlockOS 0.13.0 (amd64-efi, base)
Image: ironflockos-amd64-efi-base (build 20261105T120000Z-g1a2b3c4)
Slot A: inactive, good
Slot B: booted, good, 0.13.0 installed 2026-11-05T14:00:00Z
Next boot: slot BDer Agent eines IronFlockOS-Geräts ist der, den das Image bei der Registrierung des Geräts eingerichtet hat, in /opt/ironflock/device-agent auf /data, und er wird wie auf jedem anderen System angezeigt. Ein Gerät, das sich noch nicht registriert hat, hat keinen Agenten; das Image bringt einen mit, und die Zeile sagt, wie sich das Gerät registriert (erste Zeile unten). Konnte /data bei diesem Start nicht eingehängt werden, ist auch der Ordner des Agenten nicht zu sehen, ob registriert oder nicht, und die Zeile sagt stattdessen das (zweite Zeile):
Agent: not enrolled yet: the device enrolls with a .flock on its IRONFLOCKOS partition at its next start, or now with 'sudo ironflock agent configure -c <file>'
Agent: not to be seen: /data, which holds the agent and its .flock, could not be mounted (below); a .flock on the IRONFLOCKOS partition enrolls the device at its next start for as long as /data is missingUnter dem System erscheint jeweils eine Zeile nur dann, wenn IronFlockOS etwas zu melden hat:
| Zeile | Angezeigt, wenn |
|---|---|
Last reset: | das letzte Zurücksetzen auf Werkseinstellungen fehlgeschlagen ist oder aufgegeben wurde. os reset erklärt, was ein Eintrag bedeutet |
Reset hold: | ein Zurücksetzen nicht abgeschlossen ist (wait: Eine .flock oder proxy.conf auf der IRONFLOCKOS-Partition wird nicht übernommen, solange die Daten des bisherigen Eigentümers auf /data liegen können; copy: Das Zurücksetzen hat mit dem Löschen begonnen) oder aufgegeben wurde, ohne die .flock und proxy.conf entfernen zu können, die mit ihm kamen; sie bleiben ungenutzt (gave-up) |
/data: | /data nicht eingehängt werden konnte: Das Gerät läuft auf den eigenen Ordnern des Root-Slots, ohne Docker und die Apps |
/apps: | /apps nicht der Ordner der Datenpartition ist: Die Apps laufen, verlieren aber beim nächsten OS-Update ihre Daten |
Last reset: gave up after 3 attempts at 2026-11-11T09:00:00Z: the data partition is not the partition named data on the disk of the root slot; /data holds the old data; left of the old owner: the data partition, the booted root slot, the other root slot
Reset hold: wait: a reset is open; a .flock or proxy.conf on the IRONFLOCKOS partition is not taken while the old owner's data may be on /data
/data: NOT MOUNTED: the device runs on the root slot's own folders; Docker and the apps do not run, and what is written now is lost with the next update
/apps: not the data partition's folder: the apps run, but lose their data at the next OS updateEin fehlgeschlagener Versuch eines Zurücksetzens erscheint als attempt 1 of 3 failed at <time>: <reason>; /data holds the old data; the next start tries again, solange die Sperre wait oder copy ist, und no request is open now ohne Sperre. Ohne Root-Rechte ist der angezeigte Eintrag des Zurücksetzens seine Kopie im laufenden Slot, da die IRONFLOCKOS-Partition root gehört.
Das letzte os install
Unter jedem Linux mit EFI-Variablen zeigt eine Zeile OS install:, was das letzte ironflock os install in der EFI-Variablen IronFlockInstall von IronFlock festgehalten hat, sofern es sie gibt. Jeder Benutzer darf die Variable lesen. Wo sie sich nicht lesen lässt oder die Maschine keine EFI-Variablen hat, gibt es weder eine Zeile noch eine Warnung; ein Wert, der sich nicht parsen lässt, ergibt eine Warnung.
System: Debian GNU/Linux 13 (trixie)
OS install: 'ironflock os install' stopped at 2026-11-11T10:00:00Z before it wrote the disk: the disk /dev/sda is not the plan's: its size changed from 64.0 GB to 32.0 GB; nothing was changed, and this system runs as before| Stufe | Die Zeile sagt |
|---|---|
stopped | dass es angehalten hat, bevor es die Festplatte beschrieben hat, den Grund und dass nichts geändert wurde |
handed-over | auf dem alten System: Der Installer ist beim Neustart nicht gelaufen, und nichts wurde geändert. Unter IronFlockOS: Es hat dieses System geschrieben, konnte aber nicht festhalten, wie die Installation endete |
writing | dass es begonnen hat, die Festplatte zu beschreiben, und nicht festgehalten hat, dass es fertig wurde |
done | unter IronFlockOS: Dieses System wurde von os install installiert. Anderswo: Es hat IronFlockOS auf eine Festplatte der Maschine geschrieben, und das laufende System ist ein anderes |
failed | dass es die Festplatte beschrieben hat und sich das Geschriebene beim Zurücklesen nicht bestätigt hat, mit dem Grund |
Der Eintrag wird nie gelöscht. Die Zeile bleibt, bis das nächste os install sie ersetzt, und auf einem umgestellten Gerät bleibt sie als Vermerk, dass das System auf diese Weise installiert wurde.
JSON-Ergebnis
--json schreibt dasselbe als ein JSON-Objekt, hier auf mehreren Zeilen gezeigt; der Befehl schreibt es in einer Zeile.
{
"agent": {
"installed": true,
"layout": "current",
"dir": "/opt/ironflock/device-agent",
"version": "1.6.9",
"service": {"unit": "ironflock-device-agent.service", "state": "running"},
"connection": "unknown",
"device": "demo-device",
"swarm": "demo_swarm",
"update": {"state": "none"}
},
"appliance": {"installed": false},
"os": {"name": "Debian GNU/Linux 12 (bookworm)", "id": "debian", "version": "12", "ironflockos": false},
"needs_root": []
}Eine Angabe, die sich nicht lesen lässt, ist unknown; sind nicht fehlende Root-Rechte der Grund, sagt eine Warnung auf stderr, warum.
| Feld | Werte |
|---|---|
agent.installed | true, wenn ein Agent installiert ist. Die Felder von layout bis update sind dann vorhanden, und nur dann. Unter IronFlockOS bedeutet false, dass sich das Gerät noch nicht registriert hat |
agent.unfinished_install | true: kein Agent, aber eine frühere Installation hat angehalten, bevor sie zum Agenten kam; agent install macht sie zuerst rückgängig. Sonst nicht vorhanden |
agent.layout | current (/opt/ironflock/device-agent), legacy (/opt/reagent, von einem früheren Installer), migrating (der Agent verschiebt gerade das alte Layout in das aktuelle) |
agent.dir | der Ordner des Agenten |
agent.version | was die Binärdatei des Agenten mit -version ausgibt |
agent.service | unit und state: running, starting, stopping, stopped, failed, not_found (systemd kennt die Unit nicht), unknown |
agent.connection | disconnected, wenn der Agent nicht läuft. Die Verbindung eines laufenden Agenten ist unknown; connected kommt von Agenten, die sie melden |
agent.device, agent.swarm | der Name des Geräts und sein Projekt, aus der .flock. Sonst wird nichts aus der .flock gelesen |
agent.update | das letzte Selbst-Update. state: none (nichts in Arbeit, nichts fehlgeschlagen), activating, probation (die neue Version läuft und muss sich verbinden, um sich zu bewähren), rolled_back (es ist fehlgeschlagen, die vorherige Version läuft wieder, die neue wird später erneut versucht), blocked (es ist endgültig fehlgeschlagen; der Agent wartet auf ein neueres Release), unknown. Mit version, previous_version, reason und updated_at |
appliance.installed | true, wenn die IronFlock-Appliance installiert ist (ihre Unit ironflock.service ist vorhanden); dann sind dir, version, channel, url, license, service, health und update vorhanden |
appliance.data_left | nur wenn die Appliance nicht installiert ist und /opt/ironflock noch ihre Daten enthält, zurückgelassen von appliance remove ohne --purge oder von einer Installation, die angehalten hat: dieser Ordner |
appliance.version, appliance.channel | die Dateien VERSION und CHANNEL in ihrem Ordner |
appliance.url | die Adresse ihrer Oberfläche: HOME_URL aus ihrer .env. Sonst wird nichts aus der .env gelesen, die ihre Secrets enthält |
appliance.license | present, wenn ihre license.env einen Lizenzschlüssel enthält, missing, wenn nicht, invalid, wenn ihr LICENSE_KEY kein Lizenzschlüssel (eine UUID) ist: Jeder Befehl der Appliance ignoriert einen solchen Schlüssel, und der Text sagt das. Der Schlüssel wird nie angezeigt |
appliance.service | ironflock.service, mit denselben Zuständen wie beim Agenten. running bedeutet, dass die Unit die Container gestartet hat, nicht, dass jeder von ihnen gesund ist |
appliance.health | wie es ihren Diensten geht, aus docker ps: state healthy (jeder läuft und besteht seinen Healthcheck, hat keinen, oder ist einmal gelaufen und mit 0 beendet), starting (ein Healthcheck steht aus), unhealthy, down (kein Container), unknown; services, wie viele Container; problems, jeder Dienst, der nicht gesund ist, mit seinem state (unhealthy, starting, restarting, exited mit exit_code, …) |
appliance.update | ein wartendes Update, aus der Statusdatei, die ihre Oberfläche und ihr Wiederholungs-Timer schreiben: state none (keines angefordert, oder das letzte ist fertig), running, failed (der Wiederholungs-Timer versucht es erneut), unknown; mit version, since und message. cut_short (nur root) nennt das Release, dessen Dateien ein abgebrochenes Update aufbewahrt hat: Das nächste Update stellt sie zuerst wieder her. Es wird kein Release nachgeschlagen |
appliance.ironflock | nur wenn das ironflock, das die Units der Appliance bei jedem Start ausführen (path, /usr/local/bin/ironflock), missing oder older (state; version, was es nennt) ist als das, das die Appliance zuletzt installiert oder aktualisiert hat (installed). Nur root, und nur für eine Appliance, die ironflock installiert hat. Der Text hat dann eine Zeile ironflock:, die sagt, was zu installieren ist |
os.name, os.id, os.version | PRETTY_NAME, ID und VERSION_ID aus /etc/os-release; auf einem Mac macOS 15.5, macos, 15.5 |
os.ironflockos | true unter IronFlockOS. Dann ist os.version seine IMAGE_VERSION, und die Felder darunter folgen |
os.image, os.build | IMAGE_ID und BUILD_ID des Images |
os.booted_slot, os.primary_slot | der Slot, aus dem das System läuft, und der, den der nächste Boot startet: A oder B |
os.slots | die Root-Slots: name (A), rauc_slot (rootfs.0), state (booted, active, inactive), boot_status (good, bad) sowie version und installed_at des Release, das ein Update dort installiert hat (fehlt bei einem Slot, der mit dem Image geschrieben wurde). Fehlt, wenn sich die Slots nicht lesen lassen |
os.last_reset | der Eintrag des letzten Zurücksetzens auf Werkseinstellungen, nur wenn er failed oder gave-up ist: result, time, version, attempt, attempts_max, reason, data (old, new, none: was /data jetzt enthält) und bei gave-up left (aus data, booted-slot, other-slot: was vom bisherigen Eigentümer noch vorhanden sein kann) |
os.reset_hold | wait, copy oder gave-up, nur solange eine Reset-Sperre besteht (siehe die Tabelle oben) |
os.data_missing | true, nur wenn /data nicht eingehängt werden konnte |
os.install | was das letzte os install festgehalten hat, unter jedem Linux mit EFI-Variablen, nur wenn es vorhanden ist und sich lesen lässt: stage, time (RFC 3339, UTC) und reason (bei stopped und failed) |
os.apps_not_persistent | true, nur wenn /apps nicht der Ordner der Datenpartition ist |
needs_root | die Felder, die unknown sagen, weil der Befehl nicht als root lief, etwa agent.device und agent.swarm. Leer, wenn nichts ausgelassen wurde |
Exit-Code
Der Exit-Code ist 0, sobald die Übersicht geschrieben ist, auch wenn sie einen gestoppten Agenten, ein zurückgerolltes Update oder einen fehlerhaften Slot zeigt: status berichtet und urteilt nicht, und ein Skript liest die Felder. Er ist 1, wenn sich die Übersicht nicht schreiben lässt. Zu den anderen Exit-Codes siehe Exit-Codes.
ironflock doctor
Prüft, ob diese Maschine den Geräte-Agenten ausführen kann und ob sie die Hosts erreicht, mit denen der Agent spricht: das System, systemd, Docker, den freien Speicherplatz, die Uhr, DNS, den Proxy, den Download-Server und die Hosts, die die .flock des Geräts nennt.
ironflock doctor [flags]Läuft unter: Linux und macOS. Root-Rechte: nicht nötig; eine Prüfung, die ohne Root-Rechte nicht nachsehen kann, ist skipped und sagt das. Fragt: nichts.
| Flag | Bedeutung |
|---|---|
-c, --config <file> | die .flock-Datei des Geräts, deren Hosts geprüft werden (Standard: die des installierten Agenten) |
agent install führt diese Prüfungen aus, alle außer privileges und docker, bevor es irgendetwas ändert, und hält an, wenn system, systemd, disk_space oder download_tree fehlschlägt.
# Diese Maschine prüfen, mit Ihrem Benutzer
ironflock doctor
# Alles als root prüfen, als JSON
sudo ironflock doctor --json
# Die Hosts einer .flock prüfen, bevor Sie sie installieren
ironflock doctor -c device.flockErgebnisse
Jede Prüfung hat eine ID, ein Ergebnis und einen Befund von einer Zeile. Ein anderes Ergebnis als ok kommt mit einem Hinweis, der sagt, was zu tun ist.
| Ergebnis | Bedeutung |
|---|---|
ok | nichts zu tun |
warning | es kann funktionieren, aber nicht gut |
failed | der Agent lässt sich so, wie die Maschine ist, nicht installieren oder funktioniert nicht |
skipped | die Prüfung konnte nicht nachsehen; der Befund sagt, warum |
Prüfungen
Die Prüfungen in der Reihenfolge, in der sie angezeigt werden. Eine Prüfung behält ihre ID; eine neue Prüfung erhält eine neue.
| ID | Prüft | Wenn sie nicht ok ist |
|---|---|---|
privileges | ob der Befehl als root läuft | warning ohne Root-Rechte, wenn eine Prüfung nicht nachsehen konnte; der Befund nennt diese Prüfungen. Führen Sie sudo ironflock doctor aus |
system | Linux auf Basis von Debian oder Ubuntu (die Installation bezieht ihre Pakete über apt) oder IronFlockOS, und die Architektur, für die der Agent heruntergeladen wird | failed auf einem anderen System, warning auf einem anderen Linux mit apt. agent install hält bei failed an |
systemd | systemd betreibt das System (/run/systemd/system ist vorhanden) | failed, wenn systemd das System nicht betreibt; agent install hält dann an. warning, solange das System degraded ist: Eine Unit ist fehlgeschlagen |
docker | Docker läuft (docker info) | ok ohne Docker, da agent install es mitbringt, aber failed unter einem installierten Agenten. skipped ohne Root-Rechte, wenn der Benutzer nicht in der Gruppe docker ist |
disk_space | der freie Speicherplatz für /opt/ironflock und für /var (Docker, apt, die Logs) | failed unter 128 MiB in /opt: Eine Installation oder ein Update des Agenten hält seine Binärdatei dort doppelt vor. warning unter 2 GiB in einem der beiden |
clock | die Uhr dieser Maschine im Vergleich zum Date der Antwort des Download-Servers, zusammen mit deren Age, wenn ein Cache sie vorgehalten hat | ok innerhalb von 10 s, warning bis 5 Minuten, failed darüber: Signierte Anfragen und kurzlebige Tokens werden abgelehnt, und die Daten der Apps tragen die falsche Zeit. Eine weit abweichende Uhr bricht TLS selbst: failed, mit der Zeit, die die Maschine hat. Siehe Zeitsynchronisation (NTP) |
dns | die Namen, die diese Maschine selbst auflöst: die Hosts, die sie direkt erreicht, und den Proxy | ein Name lässt sich nicht auflösen. Einen Host, der über den Proxy erreicht wird, löst der Proxy auf |
proxy | der Proxy, über den die Netzwerkprüfungen laufen, und woher die Einstellung kommt: aus der Datei der Installation (/etc/ironflock/proxy.env), sonst aus der Umgebung | failed, wenn er nicht die URL eines Proxys ist. skipped ohne Root-Rechte, wenn die Einstellung in dieser Datei steht, die nur root liest |
download_tree | der Agent beim Download-Server, den agent install nimmt: seine Kanalzuordnung, wie agent install sie liest (device-agent/manifest-v2.json, sonst manifest.json), und der Agent des Produktionskanals für diese Architektur. Mit dem Spiegel einer Appliance wird, was der Spiegel nicht liefert, in der IronFlock-Cloud gesucht, so wie agent install es nimmt: der ganze Agent, wenn der Spiegel keine Kanalzuordnung liefert, die Datei des Agenten, wenn er die Zuordnung ohne die Datei liefert | failed, wenn es keinen Agenten zum Herunterladen gibt, mit dem Spiegel der Appliance, wenn weder der Spiegel noch die Cloud ihn hat; agent install hält dann an. Ein Serverfehler (5xx) ist eine warning, ebenso ein Agent, den die Cloud liefert, wo der Spiegel es nicht tut |
device_endpoint | die device_endpoint_url der .flock antwortet | keine Antwort: Dort verbindet sich der Agent mit IronFlock |
docker_registry | die docker_registry_url der .flock antwortet (https://<host>/v2/; mit Port einfaches HTTP, wie bei der Registry einer Appliance im LAN) | keine Antwort: Von dort lädt das Gerät die Images seiner Apps |
update_server | der Update-Server des Agenten hat seine Kanalzuordnung: die update_url der .flock (der Spiegel einer Appliance), sonst die IronFlock-Cloud | keine Antwort oder keine Kanalzuordnung: Dort findet der Agent seine Updates |
Der Download-Server ist der, den agent install nimmt: --download-base, sonst die Umgebungsvariable IRONFLOCK_DL_BASE, sonst der Download-Spiegel der Appliance, die die .flock nennt (ihre update_url, wenn das kein Host der IronFlock-Cloud ist), mit der Cloud für das, was der Spiegel nicht liefert, sonst die IronFlock-Cloud (Woher der Agent kommt). Die Hosts, die ein Gerät erreichen muss, sind unter Netzwerkanforderungen aufgeführt.
Mit und ohne -c und Root-Rechte
Die letzten drei Prüfungen brauchen eine .flock: die von -c, sonst die des installierten Agenten.
| Als root | Ohne Root-Rechte | |
|---|---|---|
Ohne -c | die Hosts der .flock des installierten Agenten | die letzten drei Prüfungen sind skipped: Die .flock des installierten Agenten gehört allein root |
Mit -c | die Hosts der angegebenen .flock | die Hosts der angegebenen .flock |
Ohne Root-Rechte ist außerdem docker außerhalb der Gruppe docker skipped, und proxy ist skipped, wenn die Installation den Proxy gespeichert hat. Eine Netzwerkprüfung, deren Host keine Antwort gibt, ist dann ebenfalls skipped (bei dns ein Name, der sich nicht auflösen lässt), da sie über den gespeicherten Proxy eine Antwort bekommen könnte. privileges nennt jede Prüfung, die nicht nachsehen konnte, und sudo ironflock doctor führt sie aus.
Wie die Netzwerkprüfungen entscheiden
- Ein Host antwortet, wenn eine HTTP-Antwort kommt, unabhängig von ihrem Status. Ein 502, 503 oder 504 auf eine einfache HTTP-Anfrage über den Proxy ist keine Antwort: Der Proxy sendet ihn, wenn er den Host nicht erreichen kann.
- Ein Zertifikat, das TLS ablehnt, ist keine Antwort. Die einzige Ausnahme ist das Zertifikat der eigenen CA einer Appliance, wenn die
.flockeineappliance_domainnennt: Der Agent vertraut ihm. - Die Prüfungen laufen über den Proxy der Prüfung
proxy, nach den Regeln vonHTTPS_PROXY,HTTP_PROXYundNO_PROXY, denen auch die Downloads folgen, auch für jede Anfrage einer Weiterleitung, und warten 20 s auf eine Antwort. - Ein Host, den ein Eintrag von
NO_PROXYvom Proxy fernhält, wird direkt angesprochen. Gibt er auf diesem Weg keine Antwort, nennt der Befund den Eintrag, zum Beispiel(directly: instance-registry.ironflock.com is in NO_PROXY), und der Hinweis sagt, den Eintrag herauszunehmen, mit dem passendenagent configure --no-proxy, wenn die Einstellung aus der Datei der Installation stammt.
Ausgabe
$ sudo ironflock doctor
Download base: https://instance-registry.ironflock.com/dl
Device file: /opt/ironflock/device-agent/device-config.flock
CHECK RESULT FINDING
privileges ok runs as root
system ok Debian GNU/Linux 12 (bookworm), amd64
systemd ok systemd runs this system
docker ok Docker 27.3.1 runs
disk_space ok 50.0 GB free for /opt and /var
clock ok within 10 s of the download server's clock
dns ok resolves instance-registry.ironflock.com, cbw.ironflock.com, europe-docker.pkg.dev
proxy ok none: the connections go direct
download_tree ok https://instance-registry.ironflock.com/dl has the agent 1.6.9 for amd64
device_endpoint ok cbw.ironflock.com answers
docker_registry failed europe-docker.pkg.dev cannot be reached: no answer within 20 s
update_server ok https://instance-registry.ironflock.com/dl has the agent's updates
What to do:
docker_registry: the device pulls its apps' images from there: let this machine reach europe-docker.pkg.dev on port 443, directly or through the proxy
Failed: docker_registry.Mit dem Spiegel der Appliance aus der .flock sagt die erste Zeile das:
Download base: http://10.0.0.5:15002/dl (the appliance's mirror of the .flock; the IronFlock cloud for what it does not give)Mit --json, hier gekürzt und auf mehreren Zeilen gezeigt; der Befehl schreibt eine Zeile.
{
"result": "failed",
"checks": [
{"id": "privileges", "result": "ok", "finding": "runs as root"},
{"id": "docker_registry", "result": "failed", "finding": "europe-docker.pkg.dev cannot be reached: no answer within 20 s", "hint": "the device pulls its apps' images from there: let this machine reach europe-docker.pkg.dev on port 443, directly or through the proxy"}
],
"download_base": "https://instance-registry.ironflock.com/dl",
"flock": "/opt/ironflock/device-agent/device-config.flock"
}| Feld | Werte |
|---|---|
result | failed, wenn eine Prüfung fehlgeschlagen ist, warning, wenn eine gewarnt hat, sonst ok. Eine übersprungene Prüfung lässt nichts fehlschlagen |
checks | die Prüfungen in der Reihenfolge oben: id, result, finding und hint bei jedem Ergebnis außer ok |
download_base | der geprüfte Download-Server. Mit dem Spiegel der Appliance nur der Spiegel; die Befunde nennen die Cloud, wenn sie dort nachsehen |
flock | die .flock, deren Hosts geprüft wurden; null ohne eine |
Keine Ausgabe zeigt ein Secret: Von einer .flock lesen die Prüfungen nur die Hosts, und das Passwort eines Proxys erscheint als xxxxx.
Exit-Code
Der Exit-Code ist 0, wenn keine Prüfung fehlgeschlagen ist; eine Warnung zählt nicht als Fehlschlag. Er ist 1, wenn eine Prüfung fehlgeschlagen ist: Das Ergebnis sagt, welche, es folgt keine Fehlerzeile, und mit --json enthält stdout das Ergebnis, kein Fehlerobjekt. Er ist 1 mit einem Fehler, wenn sich die .flock von -c nicht lesen lässt. Zu den anderen Exit-Codes siehe Exit-Codes.