Status i Doctor
ironflock status pokazuje, co z IronFlock jest na maszynie i czy działa. ironflock doctor sprawdza, czy maszyna może uruchomić agenta urządzenia i czy dociera do hostów, z którymi komunikuje się agent. Używaj ich przed podłączeniem maszyny i wtedy, gdy urządzenie nie pojawia się online.
Oba polecenia niczego nie zmieniają i o nic nie pytają. Działają w systemach Linux i macOS, bez roota, a jako root odczytują więcej. Z --host działają na innej maszynie, także na kilku naraz (Zdalne maszyny przez SSH). Tam działają jako root, gdy konto SSH jest kontem root lub może używać sudo bez hasła i bez terminala; w przeciwnym razie działają z uprawnieniami konta SSH, bez pytania, a ich wskazówka podaje polecenie z --host root@machine.
ironflock status
Pokazuje agenta urządzenia, Appliance i system operacyjny tej maszyny: co jest zainstalowane, w jakiej wersji, czy działa usługa, urządzenie i jego projekt oraz ostatnią samoaktualizację agenta. Appliance to kompletny system IronFlock na lokalnej maszynie (IronFlock Appliance); dla Appliance polecenie pokazuje też adres jego interfejsu, jego licencję, stan zdrowia jego usług i oczekującą aktualizację (Polecenia Appliance). Na IronFlockOS polecenie pokazuje też sloty systemowe i to, co wymaga uwagi.
ironflock status [flags]Działa w: Linuksie; w macOS pokazuje system i to, że nic nie jest zainstalowane. Root: niewymagany; wymaga go kilka informacji. Pyta: o nic.
Polecenie nie ma własnych flag. Przyjmuje flagi globalne (Flagi globalne).
Bez roota niektórych informacji nie da się odczytać: urządzenia i jego projektu, ponieważ plik .flock agenta należy wyłącznie do roota, a na Appliance, którego folder /opt/ironflock należy do roota, także wersji, adresu URL Appliance, jego licencji i jego aktualizacji oraz aktualizacji agenta. Stan zdrowia usług Appliance wymaga roota lub grupy docker. Mają one wartość unknown (needs root), pole JSON needs_root je wymienia, a sudo ironflock status je odczytuje.
# Co jest na tej maszynie, odczytane z uprawnieniami twojego użytkownika
ironflock status
# Wszystko, jako JSON
sudo ironflock status --json
# Status innej maszyny przez SSH
ironflock --host pi@device-17 statusWyjście tekstowe
$ 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 to projekt urządzenia. Connection ma wartość unknown dla działającego agenta: żaden z dotychczas wydanych agentów nie zgłasza swojego połączenia na maszynie.
Na IronFlockOS
Wiersz systemu pokazuje obraz i jego dwa sloty systemowe (Sloty systemowe i partycja danych):
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 BAgent urządzenia z IronFlockOS to ten, którego obraz skonfigurował przy rejestracji urządzenia, w /opt/ironflock/device-agent na /data, i jest pokazywany tak jak w każdym innym systemie. Urządzenie, które jeszcze się nie zarejestrowało, nie ma agenta; obraz zawiera agenta, a wiersz mówi, jak urządzenie się zarejestruje (pierwszy wiersz poniżej). Gdy przy tym starcie nie udało się zamontować /data, folderu agenta też nie widać, niezależnie od rejestracji, i wiersz informuje właśnie o tym (drugi wiersz):
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 missingPod systemem pojawia się po jednym wierszu, tylko gdy IronFlockOS ma coś do zgłoszenia:
| Wiersz | Pokazywany, gdy |
|---|---|
Last reset: | ostatni reset do ustawień fabrycznych nie powiódł się lub został zaniechany. os reset wyjaśnia, co oznacza wpis |
Reset hold: | reset jest otwarty (wait: plik .flock ani proxy.conf na partycji IRONFLOCKOS nie jest przyjmowany, dopóki na /data mogą być dane poprzedniego właściciela; copy: reset zaczął wymazywanie) albo reset został zaniechany i nie mógł usunąć plików .flock i proxy.conf, które z nim przyszły; pozostają one nieużywane (gave-up) |
/data: | nie udało się zamontować /data: urządzenie działa na własnych folderach slotu systemowego, bez Dockera i aplikacji |
/apps: | /apps nie jest folderem partycji danych: aplikacje działają, ale przy następnej aktualizacji systemu tracą swoje dane |
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 updateNieudana próba resetu ma postać attempt 1 of 3 failed at <time>: <reason>; /data holds the old data; the next start tries again, gdy blokada resetu ma wartość wait lub copy, a bez blokady kończy się na no request is open now. Bez roota pokazywany wpis resetu to jego kopia w działającym slocie, ponieważ partycja IRONFLOCKOS należy do roota.
Ostatnie os install
W każdym Linuksie ze zmiennymi EFI wiersz OS install: pokazuje, co ostatnie ironflock os install odnotowało w zmiennej EFI IronFlock IronFlockInstall, jeśli ta zmienna istnieje. Każdy użytkownik może ją odczytać. Gdy nie można jej odczytać albo maszyna nie ma zmiennych EFI, nie ma ani wiersza, ani ostrzeżenia; wartość, której nie da się sparsować, daje ostrzeżenie.
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| Etap | Wiersz mówi |
|---|---|
stopped | że polecenie zatrzymało się przed zapisem dysku, z przyczyną, oraz że niczego nie zmieniono |
handed-over | w starym systemie: instalator nie uruchomił się przy restarcie i niczego nie zmieniono. W IronFlockOS: polecenie zapisało ten system, ale nie mogło odnotować, jak zakończyła się instalacja |
writing | polecenie zaczęło zapisywać dysk i nie odnotowało, że skończyło |
done | w IronFlockOS: ten system zainstalowało os install. W innym systemie: polecenie zapisało IronFlockOS na dysku maszyny, a działający system jest innym systemem |
failed | polecenie zapisało dysk, a zapisanych danych nie udało się poprawnie odczytać, z przyczyną |
Wpis nigdy nie jest czyszczony. Wiersz pozostaje, dopóki następne os install go nie zastąpi, a na przekształconym urządzeniu pozostaje jako informacja, że system został zainstalowany w ten sposób.
Wynik JSON
--json zapisuje to samo jako jeden obiekt JSON, pokazany tu w kilku wierszach; polecenie zapisuje go w jednym wierszu.
{
"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": []
}Informacja, której nie można odczytać, ma wartość unknown; gdy przyczyną nie jest brak roota, ostrzeżenie na stderr mówi dlaczego.
| Pole | Wartości |
|---|---|
agent.installed | true, gdy agent jest zainstalowany. Pola od layout do update występują wtedy i tylko wtedy. Na IronFlockOS false oznacza, że urządzenie jeszcze się nie zarejestrowało |
agent.unfinished_install | true: brak agenta, ale wcześniejsza instalacja zatrzymała się, zanim doszła do agenta; agent install najpierw ją cofa. W przeciwnym razie pole nie występuje |
agent.layout | current (/opt/ironflock/device-agent), legacy (/opt/reagent, z wcześniejszego instalatora), migrating (agent właśnie przenosi starszy układ na bieżący) |
agent.dir | folder agenta |
agent.version | to, co plik binarny agenta podaje z -version |
agent.service | unit i state: running, starting, stopping, stopped, failed, not_found (systemd nie zna jednostki), unknown |
agent.connection | disconnected, gdy agent nie działa. Połączenie działającego agenta ma wartość unknown; connected pochodzi od agentów, które je zgłaszają |
agent.device, agent.swarm | nazwa urządzenia i jego projekt, z pliku .flock. Nic więcej z pliku .flock nie jest odczytywane |
agent.update | ostatnia samoaktualizacja. state: none (nic w toku, brak niepowodzeń), activating, probation (nowa wersja działa i musi się połączyć, aby się sprawdzić), rolled_back (nie powiodła się, znów działa poprzednia wersja, nowa zostanie później wypróbowana ponownie), blocked (nie powiodła się definitywnie; agent czeka na nowsze wydanie), unknown. Z version, previous_version, reason i updated_at |
appliance.installed | true, gdy IronFlock Appliance jest zainstalowany (istnieje jego jednostka ironflock.service); wtedy występują dir, version, channel, url, license, service, health i update |
appliance.data_left | tylko wtedy, gdy Appliance nie jest zainstalowany, a /opt/ironflock nadal zawiera jego dane, pozostawione przez appliance remove bez --purge albo przez instalację, która się zatrzymała: ten folder |
appliance.version, appliance.channel | pliki VERSION i CHANNEL w jego folderze |
appliance.url | adres jego interfejsu: HOME_URL z jego .env. Nic więcej z .env, który zawiera jego sekrety, nie jest odczytywane |
appliance.license | present, gdy jego license.env zawiera klucz licencyjny, missing, gdy nie, invalid, gdy jego LICENSE_KEY nie jest kluczem licencyjnym (UUID): każde polecenie Appliance ignoruje taki klucz, a tekst o tym mówi. Klucz nigdy nie jest pokazywany |
appliance.service | ironflock.service, z takimi samymi stanami jak u agenta. running oznacza, że jednostka uruchomiła kontenery, a nie że każdy z nich jest sprawny |
appliance.health | stan jego usług według docker ps: state healthy (każda działa i przechodzi swój health check albo go nie ma, albo uruchomiła się raz i zakończyła z kodem 0), starting (health check jest w toku), unhealthy, down (brak kontenera), unknown; services, liczba kontenerów; problems, każda usługa, która nie jest sprawna, z jej state (unhealthy, starting, restarting, exited z exit_code, …) |
appliance.update | oczekująca aktualizacja, według pliku stanu zapisywanego przez jego interfejs i jego timer ponawiania: state none (żadnej nie zlecono albo ostatnia się zakończyła), running, failed (timer ponawiania próbuje ponownie), unknown; z version, since i message. cut_short (tylko root) podaje wydanie, którego pliki zachowała niedokończona aktualizacja: następna aktualizacja najpierw je przywraca. Żadne wydanie nie jest wyszukiwane |
appliance.ironflock | tylko wtedy, gdy ironflock, który jednostki Appliance uruchamiają przy każdym starcie (path, /usr/local/bin/ironflock), jest missing albo older (state; version, to, co podaje) niż ten, który ostatnio zainstalował lub zaktualizował Appliance (installed). Tylko root i tylko dla Appliance zainstalowanego przez ironflock. Tekst ma wtedy wiersz ironflock:, który mówi, co zainstalować |
os.name, os.id, os.version | PRETTY_NAME, ID i VERSION_ID z /etc/os-release; na Macu macOS 15.5, macos, 15.5 |
os.ironflockos | true na IronFlockOS. Wtedy os.version to jego IMAGE_VERSION, a dalej następują poniższe pola |
os.image, os.build | IMAGE_ID i BUILD_ID obrazu |
os.booted_slot, os.primary_slot | slot, z którego działa system, i slot, który uruchomi następny rozruch: A lub B |
os.slots | sloty systemowe: name (A), rauc_slot (rootfs.0), state (booted, active, inactive), boot_status (good, bad) oraz version i installed_at wydania zainstalowanego tam przez aktualizację (nie występują dla slotu zapisanego z obrazu). Pole nie występuje, gdy slotów nie da się odczytać |
os.last_reset | wpis ostatniego resetu do ustawień fabrycznych, tylko gdy ma wartość failed lub gave-up: result, time, version, attempt, attempts_max, reason, data (old, new, none: co jest teraz na /data), a dla gave-up także left (z data, booted-slot, other-slot: co z danych poprzedniego właściciela może nadal tam być) |
os.reset_hold | wait, copy lub gave-up, tylko gdy istnieje blokada resetu (zobacz tabelę powyżej) |
os.data_missing | true, tylko gdy nie udało się zamontować /data |
os.install | co odnotowało ostatnie os install, w każdym Linuksie ze zmiennymi EFI, tylko gdy wpis istnieje i da się go odczytać: stage, time (RFC 3339, UTC) i reason (przy stopped i failed) |
os.apps_not_persistent | true, tylko gdy /apps nie jest folderem partycji danych |
needs_root | pola z wartością unknown, ponieważ polecenie nie działało jako root, takie jak agent.device i agent.swarm. Puste, gdy niczego nie pominięto |
Kod wyjścia
Kod wyjścia wynosi 0 zawsze, gdy przegląd zostanie zapisany, także gdy pokazuje zatrzymanego agenta, wycofaną aktualizację lub slot oznaczony jako zły: status raportuje i nie ocenia, a skrypt odczytuje pola. Wynosi 1, gdy przeglądu nie da się zapisać. Pozostałe kody wyjścia opisuje sekcja Kody wyjścia.
ironflock doctor
Sprawdza, czy ta maszyna może uruchomić agenta urządzenia i czy dociera do hostów, z którymi komunikuje się agent: system, systemd, Docker, wolne miejsce na dysku, zegar, DNS, proxy, serwer pobierania oraz hosty wskazane w pliku .flock urządzenia.
ironflock doctor [flags]Działa w: Linuksie i macOS. Root: niewymagany; test, który bez roota nie może sprawdzić, ma wynik skipped i informuje o tym. Pyta: o nic.
| Flaga | Znaczenie |
|---|---|
-c, --config <file> | plik .flock urządzenia, którego hosty są sprawdzane (domyślnie plik zainstalowanego agenta) |
agent install przed wprowadzeniem jakichkolwiek zmian wykonuje te testy, wszystkie poza privileges i docker, i zatrzymuje się, gdy nie powiedzie się system, systemd, disk_space lub download_tree.
# Sprawdź tę maszynę z uprawnieniami twojego użytkownika
ironflock doctor
# Sprawdź wszystko jako root, z wynikiem w JSON
sudo ironflock doctor --json
# Sprawdź hosty pliku .flock przed jego instalacją
ironflock doctor -c device.flockWyniki
Każdy test ma identyfikator, wynik i jednowierszowe ustalenie. Wynikowi innemu niż ok towarzyszy wskazówka, która mówi, co zrobić.
| Wynik | Znaczenie |
|---|---|
ok | nic do zrobienia |
warning | może działać, ale nie najlepiej |
failed | agenta nie da się zainstalować albo nie działa przy obecnym stanie maszyny |
skipped | test nie mógł sprawdzić; ustalenie mówi dlaczego |
Testy
Testy w kolejności, w jakiej są pokazywane. Test zachowuje swój identyfikator; nowy test dostaje nowy.
| Id | Sprawdza | Gdy wynik nie jest ok |
|---|---|---|
privileges | czy polecenie działa jako root | warning bez roota, gdy jakiś test nie mógł sprawdzić; ustalenie wymienia te testy. Uruchom sudo ironflock doctor |
system | Linux oparty na Debianie lub Ubuntu (instalacja bierze pakiety z apt) albo IronFlockOS oraz architektura, dla której pobierany jest agent | failed w innym systemie, warning w innym Linuksie z apt. agent install zatrzymuje się przy failed |
systemd | system działa pod kontrolą systemd (/run/systemd/system istnieje) | failed, gdy system nie działa pod kontrolą systemd; agent install wtedy się zatrzymuje. warning, gdy system jest w stanie degraded: jakaś jednostka zakończyła się błędem |
docker | Docker działa (docker info) | ok bez Dockera, ponieważ agent install go dostarcza, ale failed przy zainstalowanym agencie. skipped bez roota, gdy użytkownik nie należy do grupy docker |
disk_space | wolne miejsce dla /opt/ironflock i dla /var (Docker, apt, logi) | failed poniżej 128 MiB w /opt: instalacja lub aktualizacja agenta trzyma tam jego plik binarny dwukrotnie. warning poniżej 2 GiB w którymkolwiek z nich |
clock | zegar tej maszyny względem nagłówka Date w odpowiedzi serwera pobierania i jej Age, gdy przechowała ją pamięć podręczna | ok w granicach 10 s, warning do 5 minut, failed powyżej: podpisane żądania i krótkotrwałe tokeny są odrzucane, a dane aplikacji mają błędny czas. Zegar bardzo odbiegający od rzeczywistego psuje samo TLS: failed, z czasem, jaki ma maszyna. Zobacz Synchronizacja czasu (NTP) |
dns | nazwy, które ta maszyna rozwiązuje sama: hosty, do których dociera bezpośrednio, oraz proxy | nazwa się nie rozwiązuje. Host osiągany przez proxy rozwiązuje proxy |
proxy | proxy, przez które idą testy sieciowe, i skąd pochodzi to ustawienie: z ustawienia zapisanego przez instalację (/etc/ironflock/proxy.env), a w przeciwnym razie ze środowiska | failed, gdy nie jest to adres URL proxy. skipped bez roota, gdy ustawienie jest w pliku, który odczytuje tylko root |
download_tree | agent na serwerze pobierania, z którego korzysta agent install: jego mapa kanałów, tak jak odczytuje ją agent install (device-agent/manifest-v2.json, a w przeciwnym razie manifest.json), oraz agent kanału produkcyjnego dla tej architektury. Przy kopii lustrzanej Appliance to, czego kopia lustrzana nie udostępnia, jest szukane w chmurze IronFlock, tak jak bierze to agent install: cały agent, gdy kopia lustrzana nie udostępnia mapy kanałów, plik agenta, gdy udostępnia mapę bez pliku | failed, gdy nie ma agenta do pobrania, a przy kopii lustrzanej Appliance, gdy nie ma go ani kopia lustrzana, ani chmura; agent install wtedy się zatrzymuje. Błąd serwera (5xx) daje warning, podobnie jak agent, którego udostępnia chmura, a nie kopia lustrzana |
device_endpoint | device_endpoint_url z pliku .flock odpowiada | brak odpowiedzi: agent łączy się tam z IronFlock |
docker_registry | docker_registry_url z pliku .flock odpowiada (https://<host>/v2/; z portem przez zwykłe HTTP, jak rejestr Appliance w sieci LAN) | brak odpowiedzi: urządzenie pobiera stamtąd obrazy swoich aplikacji |
update_server | serwer aktualizacji agenta ma swoją mapę kanałów: update_url z pliku .flock (kopia lustrzana Appliance), a w przeciwnym razie chmura IronFlock | brak odpowiedzi lub mapy kanałów: agent znajduje tam swoje aktualizacje |
Serwer pobierania to ten, z którego korzysta agent install: --download-base, w przeciwnym razie zmienna środowiskowa IRONFLOCK_DL_BASE, w przeciwnym razie kopia lustrzana pobierania tego Appliance, który wskazuje plik .flock (jego update_url, gdy nie jest to host chmury IronFlock), z chmurą dla tego, czego kopia lustrzana nie udostępnia, a w przeciwnym razie chmura IronFlock (Skąd pochodzi agent). Hosty, do których musi docierać urządzenie, wymienia strona Wymagania sieciowe.
Z -c i bez niego, jako root i bez roota
Trzy ostatnie testy potrzebują pliku .flock: tego z -c, a w przeciwnym razie pliku zainstalowanego agenta.
| Jako root | Bez roota | |
|---|---|---|
Bez -c | hosty z pliku .flock zainstalowanego agenta | trzy ostatnie testy mają wynik skipped: plik .flock zainstalowanego agenta należy wyłącznie do roota |
Z -c | hosty z podanego pliku .flock | hosty z podanego pliku .flock |
Bez roota także docker ma wynik skipped poza grupą docker, a proxy ma wynik skipped, gdy instalacja zapisała proxy. Test sieciowy, którego host nie odpowiada, również ma wtedy wynik skipped (dla dns: nazwa, która się nie rozwiązuje), ponieważ odpowiedź mogłaby przyjść przez zapisane proxy. privileges wymienia każdy test, który nie mógł sprawdzić, a sudo ironflock doctor je wykonuje.
Jak decydują testy sieciowe
- Host odpowiada, gdy przychodzi odpowiedź HTTP, niezależnie od jej statusu. 502, 503 lub 504 na zwykłe żądanie HTTP przez proxy nie jest odpowiedzią: proxy zwraca je, gdy nie może dotrzeć do hosta.
- Certyfikat odrzucony przez TLS nie jest odpowiedzią. Jedynym wyjątkiem jest certyfikat własnego CA Appliance, gdy plik
.flockpodajeappliance_domain: agent mu ufa. - Testy idą przez proxy z testu
proxy, według regułHTTPS_PROXY,HTTP_PROXYiNO_PROXY, których przestrzegają pobierania, także dla każdego żądania przekierowania, i czekają 20 s na odpowiedź. - Host, który wpis w
NO_PROXYwyłącza z proxy, jest osiągany bezpośrednio. Gdy w ten sposób nie odpowiada, ustalenie wskazuje ten wpis, na przykład(directly: instance-registry.ironflock.com is in NO_PROXY), a wskazówka każe usunąć wpis i podaje polecenieagent configure --no-proxy, które to robi, gdy ustawienie zapisała instalacja.
Wyjście
$ 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.Przy kopii lustrzanej Appliance z pliku .flock mówi o tym pierwszy wiersz:
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)Z --json, tutaj skrócone i pokazane w kilku wierszach; polecenie zapisuje jeden wiersz.
{
"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"
}| Pole | Wartości |
|---|---|
result | failed, gdy jakiś test się nie powiódł, warning, gdy któryś zgłosił ostrzeżenie, w przeciwnym razie ok. Pominięty test nie powoduje niepowodzenia |
checks | testy, w kolejności podanej powyżej: id, result, finding oraz hint przy każdym wyniku poza ok |
download_base | sprawdzony serwer pobierania. Przy kopii lustrzanej Appliance tylko kopia lustrzana; ustalenia podają chmurę, gdy tam szukają |
flock | plik .flock, którego hosty sprawdzono; null, gdy go nie ma |
Żadne wyjście nie pokazuje sekretu: z pliku .flock testy odczytują tylko hosty, a hasło proxy jest pokazywane jako xxxxx.
Kod wyjścia
Kod wyjścia wynosi 0, gdy żaden test nie zakończył się niepowodzeniem; ostrzeżenie nie jest niepowodzeniem. Wynosi 1, gdy jakiś test zakończył się niepowodzeniem: wynik mówi który, nie następuje po nim wiersz błędu, a z --json stdout zawiera wynik, a nie obiekt błędu. Wynosi 1 z błędem, gdy nie da się odczytać pliku .flock z -c. Pozostałe kody wyjścia opisuje sekcja Kody wyjścia.