claude-botandClaude Opus 5
e3dea169b0
The image shipped without [unix_http_server], [rpcinterface:supervisor] or [supervisorctl], so supervisorctl could not connect: Error: .ini file does not include supervisorctl section That means no way to query or restart an individual service inside the container -- docker logs was the only introspection. Per-service lifecycle management was the whole argument for running a supervisor instead of one process per container, and the first revision did not actually deliver it. Unix socket only, inside the container. Nothing outside needs it, and this container runs with host networking, so a TCP listener would be exposed on the host. The build-time self-test now asserts the section exists and supervisorctl runs, so this cannot regress silently the way it shipped. NOT fixed here, because my diagnosis was wrong: the repeated "mqtt broker disconnected. reason_code = Unspecified error" is not a client ID collision. E3onCAN has no -mcid option at all -- verified against the pinned source -- and generates its own ID; the native broker log showed E3onCANclient.py-e380-7f847281 alongside open3e-edge, so the two never collided. I nearly "fixed" it by passing a flag that does not exist. Telemetry is flowing (each reconnect succeeds), so this is churn rather than an outage, but the cause is still unidentified. The next step is the broker's own log on edge-1 -- mosquitto records the disconnect reason, which the client side reports only as "Unspecified error". Co-Authored-By: Claude Bot <claude-bot@renner.uno> Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>