KamoCRM

Probe the bridge's real health, not a port that is always open

FixKlusterServices
Shipped
29 ஆகஸ்ட், 2026 அன்று 2:57 AM UTC
Author
Kamo
Commit
9112205

kamo-meet let one person into a meeting and then ended it the moment a second joined. The bridge had been hard-unhealthy for 41 hours: an in-place container restart on 2026-08-27 came up with "Failed to bind single-port", and ice4j builds that harvester ONCE at startup and never retries, so the process can never recover on its own. One participant hid it completely -- jicofo allocates no bridge for a lone occupant. The second join triggered **************** hit "no operational bridges", and jicofo tore down BOTH participants and stopped the conference. That is the whole reported symptom. Nothing restarted the pod because the probes were a bare TCP connect to 9090. Jetty binds 9090 regardless of ICE state, so the probe reported healthy for the entire 41 hours while every two-person meeting died. The probe could not observe the only failure that matters. It now reads /about/health, which returns 500 for exactly this state, so the restart -- the only recovery available -- actually happens. It has to exec curl against 127.0.0.1: the pod is hostNetwork and the node DNATs <hostIP>:8080 to Traefik, so an httpGet probe gets Traefik's 404 rather than the bridge's health. Verified both ways before settling on exec. JVB_OHTTP_SERVER_PORT="-1" went with it. It claimed to close 8080 over a CockroachDB conflict, but CRDB is retired and the image never honoured the variable -- 8080 listened the whole time -- so it only misled.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing