Skip to Content

status 및 doctor

ironflock status는 머신에 IronFlock의 무엇이 있고 실행 중인지 보여 줍니다. ironflock doctor는 머신이 디바이스 에이전트를 실행할 수 있는지, 그리고 에이전트가 통신하는 호스트에 도달하는지 검사합니다. 머신을 연결하기 전에, 그리고 디바이스가 온라인이 되지 않을 때 사용하십시오.

두 명령 모두 아무것도 변경하지 않고 아무것도 묻지 않습니다. Linux와 macOS에서 root 없이 실행되며, root로 실행하면 더 많이 읽습니다. --host를 사용하면 다른 머신에서, 여러 머신에서 동시에도 실행됩니다(SSH를 통한 원격 머신). 그곳에서는 로그인 계정이 root이거나 비밀번호와 터미널 없이 sudo를 사용할 수 있으면 root로 실행됩니다. 그렇지 않으면 묻지 않고 로그인 계정으로 실행되며, 힌트에 --host root@machine을 사용한 명령이 나옵니다.

ironflock status

이 머신의 디바이스 에이전트, 어플라이언스, 운영체제를 보여 줍니다. 무엇이 설치되어 있는지, 그 버전, 서비스가 실행 중인지, 디바이스와 그 프로젝트, 에이전트의 마지막 자체 업데이트가 나옵니다. 어플라이언스는 현장의 머신에서 실행되는 완전한 IronFlock 시스템입니다(IronFlock Appliance). 어플라이언스에 대해서는 UI 주소, 라이선스, 서비스의 상태, 대기 중인 업데이트도 보여 줍니다(어플라이언스 명령). IronFlockOS에서는 루트 슬롯과 주의가 필요한 사항도 보여 줍니다.

ironflock status [flags]

실행 환경: Linux. macOS에서는 시스템과 함께 아무것도 설치되어 있지 않다고 표시합니다. root 권한: 필요 없음. 일부 정보에는 필요합니다. 질문: 없음.

이 명령에는 자체 플래그가 없습니다. 전역 플래그를 받습니다(전역 플래그).

root가 아니면 일부 정보를 읽을 수 없습니다. 에이전트의 .flock은 root만 읽을 수 있으므로 디바이스와 그 프로젝트를 읽을 수 없고, 폴더 /opt/ironflock이 root 소유인 어플라이언스에서는 버전, 어플라이언스의 URL, 라이선스와 업데이트, 그리고 에이전트의 업데이트도 읽을 수 없습니다. 어플라이언스 서비스의 상태를 읽으려면 root 또는 docker 그룹이 필요합니다. 이런 항목에는 unknown (needs root)라고 표시되고, JSON 필드 needs_root에 나열되며, sudo ironflock status로 읽을 수 있습니다.

# 로그인 계정으로 읽은, 이 머신에 있는 것 ironflock status # 모든 정보를 JSON으로 sudo ironflock status --json # SSH로 다른 머신의 상태 확인 ironflock --host pi@device-17 status

텍스트 출력

$ 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은 디바이스의 프로젝트입니다. 실행 중인 에이전트의 Connection은 unknown입니다. 지금까지 릴리스된 에이전트는 머신에서 자신의 연결 상태를 보고하지 않습니다.

IronFlockOS에서

시스템 줄에는 이미지와 두 루트 슬롯이 나옵니다(루트 슬롯과 데이터 파티션):

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 B

IronFlockOS 디바이스의 에이전트는 디바이스가 등록될 때 이미지가 설정한 에이전트로, /data의 /opt/ironflock/device-agent에 있으며 다른 시스템에서와 똑같이 표시됩니다. 아직 등록되지 않은 디바이스에는 에이전트가 없습니다. 에이전트는 이미지에 들어 있으며, 이 줄에 디바이스가 등록되는 방법이 나옵니다(아래 첫 번째 줄). 이번 시작 때 /data를 마운트할 수 없었다면 등록 여부와 관계없이 에이전트의 폴더도 볼 수 없으며, 이 줄은 대신 그 사실을 알려 줍니다(두 번째 줄):

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 missing

시스템 아래에는 IronFlockOS가 알릴 것이 있을 때만 다음 줄이 하나씩 나타납니다:

줄표시되는 경우
Last reset:마지막 공장 초기화가 실패했거나 포기된 경우. 기록의 의미는 os reset에서 설명합니다
Reset hold:재설정이 아직 끝나지 않은 경우(wait: 이전 소유자의 데이터가 /data에 있을 수 있는 동안 IRONFLOCKOS 파티션의 .flock이나 proxy.conf를 사용하지 않음. copy: 재설정이 지우기 시작함), 또는 재설정이 포기되었고 함께 온 .flock과 proxy.conf를 제거하지 못해 사용되지 않은 채 남아 있는 경우(gave-up)
/data:/data를 마운트할 수 없는 경우: 디바이스가 Docker와 앱 없이 루트 슬롯 자체의 폴더로 실행됨
/apps:/apps가 데이터 파티션의 폴더가 아닌 경우: 앱은 실행되지만 다음 OS 업데이트 때 데이터를 잃음
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 update

재설정 시도가 실패하면, 보류가 wait 또는 copy인 동안에는 attempt 1 of 3 failed at <time>: <reason>; /data holds the old data; the next start tries again으로, 보류가 없으면 no request is open now로 표시됩니다. root가 아니면 IRONFLOCKOS 파티션이 root 소유이므로, 실행 중인 슬롯에 있는 재설정 기록의 사본이 표시됩니다.

마지막 os install

EFI 변수가 있는 모든 Linux에서, 마지막 ironflock os install이 IronFlock의 EFI 변수 IronFlockInstall에 기록한 내용이 있으면 OS install: 줄에 표시됩니다. 모든 사용자가 이 변수를 읽을 수 있습니다. 변수를 읽을 수 없거나 머신에 EFI 변수가 없으면 줄도 경고도 나오지 않습니다. 파싱되지 않는 값은 경고로 표시됩니다.

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
단계줄의 내용
stopped디스크에 쓰기 전에 중단했다는 것, 그 이유, 그리고 아무것도 변경되지 않았다는 것
handed-over이전 시스템에서: 재시작 때 설치 프로그램이 실행되지 않았고, 아무것도 변경되지 않음. IronFlockOS에서: 이 시스템을 썼지만 설치가 어떻게 끝났는지 기록하지 못함
writing디스크에 쓰기 시작했지만 끝났다는 기록을 남기지 못함
doneIronFlockOS에서: 이 시스템은 os install로 설치됨. 그 밖의 시스템에서: 머신의 디스크에 IronFlockOS를 썼으며, 실행 중인 시스템은 그와 다른 시스템임
failed디스크에 썼지만 쓴 내용을 다시 읽어 확인하지 못함, 그리고 그 이유

기록은 지워지지 않습니다. 이 줄은 다음 os install이 기록을 바꿀 때까지 남으며, 전환된 디바이스에서는 시스템이 이 방법으로 설치되었다는 표시로 남습니다.

JSON 결과

--json은 같은 내용을 하나의 JSON 객체로 씁니다. 여기서는 여러 줄로 보여 주지만, 명령은 한 줄로 씁니다.

{ "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": [] }

읽을 수 없는 정보는 unknown입니다. root 권한 외의 이유라면 stderr의 경고가 그 이유를 알려 줍니다.

필드값
agent.installed에이전트가 설치되어 있으면 true. 이때만 layout부터 update까지의 필드가 있습니다. IronFlockOS에서 false는 디바이스가 아직 등록되지 않았다는 뜻입니다
agent.unfinished_installtrue: 에이전트는 없지만 이전 설치가 에이전트 단계에 이르기 전에 중단됨. agent install이 먼저 이를 되돌립니다. 그 밖에는 없음
agent.layoutcurrent(/opt/ironflock/device-agent), legacy(이전 설치 프로그램이 만든 /opt/reagent), migrating(에이전트가 지금 legacy 구성을 current 구성으로 옮기는 중)
agent.dir에이전트의 폴더
agent.version에이전트 바이너리가 -version으로 출력하는 값
agent.serviceunit과 state: running, starting, stopping, stopped, failed, not_found(systemd가 유닛을 모름), unknown
agent.connection에이전트가 실행 중이 아니면 disconnected. 실행 중인 에이전트의 연결은 unknown이며, connected는 연결 상태를 보고하는 에이전트에서만 나옵니다
agent.device, agent.swarm.flock에 있는 디바이스 이름과 그 프로젝트. .flock의 다른 내용은 읽지 않습니다
agent.update마지막 자체 업데이트. state: none(진행 중인 것도 실패한 것도 없음), activating, probation(새 버전이 실행 중이며, 연결해서 정상임을 증명해야 함), rolled_back(실패하여 이전 버전이 다시 실행 중이며, 새 버전은 나중에 다시 시도됨), blocked(최종적으로 실패함. 에이전트는 더 새로운 릴리스를 기다림), unknown. version, previous_version, reason, updated_at과 함께 나옵니다
appliance.installedIronFlock 어플라이언스가 설치되어 있으면(유닛 ironflock.service가 있으면) true. 이때 dir, version, channel, url, license, service, health, update가 있습니다
appliance.data_left어플라이언스가 설치되어 있지 않은데 /opt/ironflock에 아직 그 데이터가 있을 때만 있음: 그 폴더. --purge 없는 appliance remove나 중단된 설치가 남긴 것입니다
appliance.version, appliance.channel어플라이언스 폴더의 VERSION과 CHANNEL 파일
appliance.urlUI의 주소: .env의 HOME_URL. 시크릿이 들어 있는 .env의 다른 내용은 읽지 않습니다
appliance.licenselicense.env에 라이선스 키가 있으면 present, 없으면 missing, 그 LICENSE_KEY가 라이선스 키(UUID)가 아니면 invalid. 이런 키는 어플라이언스의 모든 명령이 무시하며, 텍스트 출력이 그렇다고 알려 줍니다. 키는 절대 표시하지 않습니다
appliance.serviceironflock.service. 상태 값은 에이전트와 같습니다. running은 유닛이 컨테이너를 시작했다는 뜻이지, 각 컨테이너가 정상이라는 뜻은 아닙니다
appliance.healthdocker ps로 본 서비스의 상태: state는 healthy(각 서비스가 실행 중이며 상태 검사를 통과하거나, 상태 검사가 없거나, 한 번 실행되고 0으로 끝남), starting(상태 검사 대기 중), unhealthy, down(컨테이너 없음), unknown. services는 컨테이너 수. problems는 정상이 아닌 각 서비스와 그 state(unhealthy, starting, restarting, exit_code와 함께 exited 등)
appliance.updateUI와 재시도 타이머가 쓰는 상태 파일에서 읽은, 대기 중인 업데이트: state는 none(요청된 것이 없거나 마지막 업데이트가 끝남), running, failed(재시도 타이머가 다시 시도함), unknown. version, since, message와 함께 나옵니다. cut_short(root만)는 중단된 업데이트가 파일을 보관한 릴리스를 나타냅니다. 다음 업데이트는 먼저 그 파일을 되돌립니다. 릴리스를 조회하지는 않습니다
appliance.ironflock어플라이언스의 유닛이 시작할 때마다 실행하는 ironflock(path, /usr/local/bin/ironflock)이 없거나(missing) 어플라이언스를 마지막으로 설치하거나 업데이트한 ironflock(installed)보다 오래된(older) 경우에만 있음(state. version은 그 바이너리가 알려 주는 버전). root만, 그리고 ironflock이 설치한 어플라이언스에서만 해당합니다. 이때 텍스트 출력에 ironflock: 줄이 나오며, 무엇을 설치해야 하는지 알려 줍니다
os.name, os.id, os.version/etc/os-release의 PRETTY_NAME, ID, VERSION_ID. Mac에서는 macOS 15.5, macos, 15.5
os.ironflockosIronFlockOS에서 true. 이때 os.version은 그 IMAGE_VERSION이며, 아래 필드가 이어집니다
os.image, os.build이미지의 IMAGE_ID와 BUILD_ID
os.booted_slot, os.primary_slot시스템이 실행 중인 슬롯과 다음 부팅 때 시작할 슬롯: A 또는 B
os.slots루트 슬롯: name(A), rauc_slot(rootfs.0), state(booted, active, inactive), boot_status(good, bad), 그리고 업데이트가 그 슬롯에 설치한 릴리스의 version과 installed_at(이미지로 쓴 슬롯에는 없음). 슬롯을 읽을 수 없으면 없음
os.last_reset마지막 공장 초기화의 기록으로, failed 또는 gave-up일 때만 있음: result, time, version, attempt, attempts_max, reason, data(old, new, none: 지금 /data에 있는 것), 그리고 gave-up이면 left(data, booted-slot, other-slot 중 이전 소유자의 것이 아직 남아 있을 수 있는 것)
os.reset_hold재설정 보류가 있는 동안에만 wait, copy 또는 gave-up(위 표 참조)
os.data_missing/data를 마운트할 수 없었을 때만 true
os.install마지막 os install이 기록한 내용. EFI 변수가 있는 모든 Linux에서, 기록이 있고 읽을 수 있을 때만 있음: stage, time(RFC 3339, UTC), reason(stopped와 failed일 때)
os.apps_not_persistent/apps가 데이터 파티션의 폴더가 아닐 때만 true
needs_root명령이 root로 실행되지 않아 unknown인 필드. 예: agent.device, agent.swarm. 빠진 것이 없으면 비어 있음

종료 코드

개요를 쓰면 종료 코드는 항상 0입니다. 개요에 중지된 에이전트, 롤백된 업데이트, 불량 슬롯이 나와도 마찬가지입니다. status는 보고만 하고 판단하지 않으며, 스크립트가 필드를 읽어 판단합니다. 개요를 쓸 수 없으면 1입니다. 그 밖의 종료 코드는 종료 코드를 참조하십시오.

ironflock doctor

이 머신이 디바이스 에이전트를 실행할 수 있는지, 그리고 에이전트가 통신하는 호스트에 도달하는지 검사합니다. 시스템, systemd, Docker, 디스크 여유 공간, 시계, DNS, 프록시, 다운로드 서버, 그리고 디바이스의 .flock에 지정된 호스트를 검사합니다.

ironflock doctor [flags]

실행 환경: Linux와 macOS. root 권한: 필요 없음. root 없이 살펴볼 수 없는 검사는 skipped이며 그 사실을 알려 줍니다. 질문: 없음.

플래그의미
-c, --config <file>호스트를 검사할 디바이스의 .flock 파일(기본값: 설치된 에이전트의 파일)

agent install은 아무것도 변경하기 전에 privileges와 docker를 제외한 이 검사를 모두 실행하며, system, systemd, disk_space 또는 download_tree가 실패하면 중단합니다.

# 로그인 계정으로 이 머신 검사 ironflock doctor # root로 모든 항목을 검사하고 JSON으로 출력 sudo ironflock doctor --json # .flock을 설치하기 전에 그 호스트 검사 ironflock doctor -c device.flock

결과

각 검사에는 ID, 결과, 한 줄짜리 진단 내용이 있습니다. ok가 아닌 결과에는 무엇을 해야 하는지 알려 주는 힌트가 함께 나옵니다.

결과의미
ok할 일 없음
warning동작할 수는 있지만 원활하지 않을 수 있음
failed머신의 현재 상태로는 에이전트를 설치할 수 없거나 에이전트가 동작하지 않음
skipped검사가 살펴볼 수 없었음. 진단 내용에 이유가 나옴

검사 항목

검사는 표시되는 순서대로 나열되어 있습니다. 검사의 ID는 바뀌지 않으며, 새 검사는 새 ID를 받습니다.

ID살펴보는 대상ok가 아닐 때
privileges명령이 root로 실행되는지root가 아니어서 살펴볼 수 없었던 검사가 있으면 warning. 진단 내용에 그 검사들이 나옵니다. sudo ironflock doctor를 실행하십시오
systemLinux이고 Debian 또는 Ubuntu 기반(설치가 apt에서 패키지를 가져옴)이거나 IronFlockOS인지, 그리고 에이전트를 다운로드할 아키텍처다른 시스템이면 failed, apt가 있는 다른 Linux이면 warning. agent install은 failed에서 중단합니다
systemdsystemd가 시스템을 실행하는지(/run/systemd/system이 있는지)systemd가 시스템을 실행하지 않으면 failed이며, 이때 agent install은 중단합니다. 시스템이 degraded 상태이면(유닛이 실패함) warning
dockerDocker가 실행 중인지(docker info)agent install이 Docker를 설치하므로 Docker가 없어도 ok이지만, 에이전트가 설치되어 있는데 Docker가 없으면 failed. root가 아니고 사용자가 docker 그룹에 없으면 skipped
disk_space/opt/ironflock과 /var(Docker, apt, 로그)의 여유 공간/opt가 128 MiB 미만이면 failed: 에이전트를 설치하거나 업데이트할 때 바이너리를 그곳에 두 벌 보관합니다. 어느 쪽이든 2 GiB 미만이면 warning
clock이 머신의 시계를 다운로드 서버 응답의 Date와 비교하며, 캐시가 응답을 보관했으면 그 Age도 반영10초 이내면 ok, 5분까지는 warning, 그 이상이면 failed: 서명된 요청과 수명이 짧은 토큰이 거부되고, 앱의 데이터에 잘못된 시간이 기록됩니다. 시계가 크게 어긋나면 TLS 자체가 실패합니다. 이때는 failed이며 머신의 시간이 함께 표시됩니다. 시간 동기화 (NTP)를 참조하십시오
dns이 머신이 직접 확인하는 이름: 직접 도달하는 호스트와 프록시이름이 확인되지 않음. 프록시를 통해 도달하는 호스트는 프록시가 확인합니다
proxy네트워크 검사가 거치는 프록시와 그 설정의 출처: 설치 기록(/etc/ironflock/proxy.env), 없으면 환경 변수프록시 URL이 아니면 failed. 기록이 root만 읽을 수 있는 파일에 있는데 root가 아니면 skipped
download_treeagent install이 사용하는 다운로드 서버의 에이전트: agent install이 읽는 채널 맵(device-agent/manifest-v2.json, 없으면 manifest.json)과 이 아키텍처용 프로덕션 채널의 에이전트. 어플라이언스의 미러를 사용하면, 미러가 제공하지 않는 것은 agent install과 마찬가지로 IronFlock 클라우드에서 찾습니다. 미러가 채널 맵을 제공하지 않으면 에이전트 전체를, 맵은 제공하지만 파일이 없으면 에이전트 파일을 찾습니다다운로드할 에이전트가 없으면 failed이며(어플라이언스의 미러를 사용할 때는 미러에도 클라우드에도 없으면), 이때 agent install은 중단합니다. 서버 오류(5xx)는 warning이며, 미러가 아니라 클라우드가 제공하는 에이전트도 warning입니다
device_endpoint.flock의 device_endpoint_url이 응답하는지응답 없음: 에이전트는 그곳에서 IronFlock에 연결합니다
docker_registry.flock의 docker_registry_url이 응답하는지(https://<host>/v2/. 포트가 있으면 LAN에 있는 어플라이언스의 레지스트리처럼 일반 HTTP)응답 없음: 디바이스는 그곳에서 앱의 이미지를 가져옵니다
update_server에이전트의 업데이트 서버에 채널 맵이 있는지: .flock의 update_url(어플라이언스의 미러), 없으면 IronFlock 클라우드응답이 없거나 채널 맵이 없음: 에이전트는 그곳에서 업데이트를 찾습니다

다운로드 서버는 agent install이 사용하는 서버입니다. --download-base, 없으면 환경 변수 IRONFLOCK_DL_BASE, 그것도 없으면 .flock이 지정하는 어플라이언스의 다운로드 미러(update_url이 IronFlock 클라우드의 호스트가 아닐 때)와 미러가 제공하지 않는 것을 위한 클라우드, 그 밖에는 IronFlock 클라우드입니다(에이전트를 가져오는 곳). 디바이스가 도달해야 하는 호스트는 네트워크 요구 사항에 나와 있습니다.

-c와 root 권한 유무에 따른 차이

마지막 세 검사에는 .flock이 필요합니다. -c의 파일을 사용하고, 없으면 설치된 에이전트의 파일을 사용합니다.

root로 실행root 없이 실행
-c 없음설치된 에이전트 .flock의 호스트마지막 세 검사는 skipped: 설치된 에이전트의 .flock은 root만 읽을 수 있습니다
-c 있음지정한 .flock의 호스트지정한 .flock의 호스트

root가 아니면 docker 그룹 밖에서는 docker도 skipped이고, 설치가 프록시를 기록했으면 proxy도 skipped입니다. 이때 호스트가 응답하지 않는 네트워크 검사도 skipped입니다(dns는 확인되지 않는 이름). 기록된 프록시를 거치면 응답을 받을 수도 있기 때문입니다. privileges가 살펴볼 수 없었던 검사를 모두 알려 주며, sudo ironflock doctor로 실행하면 그 검사도 실행됩니다.

네트워크 검사의 판단 기준

  • HTTP 응답이 오면 상태 코드와 관계없이 호스트가 응답한 것입니다. 프록시를 거친 일반 HTTP 요청에 대한 502, 503, 504는 응답이 아닙니다. 프록시가 호스트에 도달할 수 없을 때 이런 응답을 주기 때문입니다.
  • TLS가 거부하는 인증서는 응답이 아닙니다. 유일한 예외는 .flock에 appliance_domain이 지정된 경우의 어플라이언스 자체 CA 인증서입니다. 에이전트가 이 인증서를 신뢰합니다.
  • 검사는 proxy 검사의 프록시를 거치며, 다운로드가 따르는 HTTPS_PROXY, HTTP_PROXY, NO_PROXY 규칙을 리디렉션의 모든 요청에도 적용하고, 응답을 20초 기다립니다.
  • NO_PROXY 항목 때문에 프록시를 거치지 않는 호스트는 직접 연결합니다. 이렇게 해서 응답이 없으면 진단 내용에 그 항목이 나오고(예: (directly: instance-registry.ironflock.com is in NO_PROXY)), 힌트는 그 항목을 빼라고 안내합니다. 설정이 설치 기록에 있으면 이를 처리하는 agent configure --no-proxy도 함께 안내합니다.

출력

$ 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.

.flock의 어플라이언스 미러를 사용하면 첫 줄이 그렇다고 알려 줍니다:

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)

--json을 사용한 출력입니다. 여기서는 줄여서 여러 줄로 보여 주지만, 명령은 한 줄로 씁니다.

{ "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" }
필드값
result실패한 검사가 있으면 failed, 경고한 검사가 있으면 warning, 그 밖에는 ok. 건너뛴 검사는 결과를 실패로 만들지 않습니다
checks위 순서대로의 검사: id, result, finding, 그리고 ok를 제외한 모든 결과에 hint
download_base검사한 다운로드 서버. 어플라이언스의 미러를 사용하면 미러만 나오며, 클라우드에서 찾은 경우에는 진단 내용이 클라우드를 알려 줍니다
flock호스트를 검사한 .flock. 없으면 null

어떤 출력에도 시크릿은 나오지 않습니다. 검사는 .flock에서 호스트만 읽으며, 프록시 비밀번호는 xxxxx로 표시됩니다.

종료 코드

실패한 검사가 없으면 종료 코드는 0입니다. 경고는 실패가 아닙니다. 검사가 실패하면 1입니다. 이때 결과에 어떤 검사인지 나오고, 오류 줄은 이어지지 않으며, --json을 사용하면 stdout에는 오류 객체가 아니라 결과가 나옵니다. -c의 .flock을 읽을 수 없으면 오류와 함께 1입니다. 그 밖의 종료 코드는 종료 코드를 참조하십시오.

Last updated on