# your container will show unhealthy while serving perfectly

> llama.cpp server-ի image-ը բերում է 8080 պորտին ուղղված healthcheck; գործարկեք սերվերն այլ պորտի վրա, և Docker-ը կոնտեյները կնշի որպես unhealthy, մինչդեռ այն անթերի սպասարկում է։ Ներքին պորտը պահեք 8080-ի վրա կամ վերասահմանեք ստուգումը։

- Platform: Ցանկացած լոկալ ստեկ
- Runtime: llama.cpp server (Docker)
- Published: 2026-09-02
- Sources: https://agmind.ai/hy/guides/deploy-llm-strix-halo/, https://agmind.ai/hy/essays/dashboard-lies-both-directions/
- Canonical: https://agmind.ai/hy/symptoms/container-unhealthy-while-serving-healthcheck-port/

## Ինչ եք տեսնում

`docker ps`-ն աշխատող llama.cpp server կոնտեյները նշում է որպես `unhealthy`,
մինչդեռ դրա հետևում կանգնած սերվերը պատասխանում է ամեն իրական հարցման։
Կոնտեյների վերագործարկումը ոչինչ չի փոխում։ `docker inspect`-ը ցույց է
տալիս, որ ներկառուցված healthcheck-ը զոնդում է `localhost:8080/health`-ը,
իսկ սերվերը գործարկվել է `--port`-ով, որին ուրիշ արժեք է տրված։

## Որտեղ ենք հանդիպել

Լաբորատորիայի տուփերից մեկի վրա, 2026-ի օգոստոսի կեսերին. երկու նոր
տեղակայված թեստային մոդել, գործարկված 8090 և 8091 պորտերի վրա։ Երկու
կոնտեյներն էլ սպասարկելիս unhealthy էին երևում։ Տեղակայման
ուղեցույցն իր սեփական Strix Halo ուղում այդ դեպքին հղում է որպես թակարդ,
որտեղ `ghcr.io/ggml-org/llama.cpp:server-vulkan`-ն աշխատում է
Ryzen AI Max+ 395 տուփի վրա։ Երկու էջերից ոչ մեկը image-ի build-ի համարը
չի գրանցում; ուղեցույցն այն քաշում է tag-ով և ասում է նորից քաշել
digest-ով, երբ ամեն ինչ աշխատի։

## Պատճառ

Image-ը բերում է լռելյայն healthcheck, որը կոնտեյների ներսում զոնդում է
`localhost:8080/health`-ը։ Տվեք ուրիշ `--port`, և սերվերը լսում է
այնտեղ, իսկ զոնդը շարունակում է հարցնել 8080-ին։ Ոչ ոք չի պատասխանում,
Docker-ը ստատուսի սյունակում դրոշմում է `unhealthy`, իսկ սյունակը
«զոնդը սխալ է կարգավորված»-ի համար գույն չունի, միայն «մեռած»-ի համար։
Վերագործարկված կոնտեյները ժառանգում է նույն զոնդը, ուստի նույն կերպ էլ
ձախողվում է։

## Լուծում

Ուղեցույցից երկու տարբերակ. ներքին պորտը պահել 8080-ի վրա կամ
վերասահմանել healthcheck-ը։ Ուղեցույցի սերվինգի հրամանն անում է առաջինը՝
`--port 8080` կոնտեյների ներսում, հրապարակված որպես `-p 8080:8080`.

```
docker run -d --name llm-server \
  --device /dev/dri --device /dev/kfd \
  -v /var/lib/llm/models:/models \
  -p 8080:8080 \
  ghcr.io/ggml-org/llama.cpp:server-vulkan \
  -m /models/YOUR-MODEL.gguf \
  -ngl 999 -fa on -c 32768 \
  --host 0.0.0.0 --port 8080 --jinja
```

Եթե `--port`-ն այնուամենայնիվ պետք է տեղափոխել, healthcheck-ը
վերասահմանեք դրան համապատասխան; ուղեցույցն այդ վերասահմանումը չի բերում։
Ապա հարցրեք պրոցեսին, ոչ թե ձեր հրամանի տողին, հոսթի այն պորտի վրա,
որը հրապարակել եք (8080՝ ուղեցույցի `-p 8080:8080`-ի դեպքում).

```
curl -s localhost:8080/props | python3 -m json.tool | head -40
```

Դա ցույց է տալիս, թե ինչ է աշխատեցնում պրոցեսը. `n_ctx`-ը, մոդելի ուղին,
slot-երի քանակը։ Թե արդյոք այն պատասխանում է, ուղեցույցի հաջորդ քայլն է՝
իրական chat completion, որում ստուգվում են ոչ դատարկ `content`-ը և `stop`
finish reason-ը։

Լաբորատորիայի harness-ի ներսում կանոնը դարձավ սա. healthcheck-երը
թիրախավորում են հենց այն endpoint-ն ու պորտը, որոնց համար բջիջը
կարգավորված է, և արագ ձախողվում են, երբ այն չի պատասխանում։

## Բա՞ց է դեռ upstream-ում

Մենք չենք հետևում։ Աղբյուր էջերից ոչ մեկը upstream issue չի նշում։

## Ապացույցներ

- [Տեղակայել լոկալ LLM Strix Halo-ի վրա](https://agmind.ai/hy/guides/deploy-llm-strix-halo/),
  Քայլ 3, պորտի նշումը սերվինգի հրամանի կողքին։
- [Դաշբորդը մեկ օրում ստեց երկու անգամ՝ հակառակ ուղղություններով](https://agmind.ai/hy/essays/dashboard-lies-both-directions/),
  «Կարմիր, բայց առողջ», դեպքն այնպես, ինչպես տեղի ունեցավ։

---

Machine-readable claim registry: https://agmind.ai/claims.json · llms.txt: https://agmind.ai/llms.txt