admin/bri-sandbox-development-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

DEPLOY.md: also check what's bound to port 3452 when curl works

Browse Source 
If something else is also listening on :3452 (a leftover
container, a systemd-managed socket, a proxy from an earlier
session), the kernel can route new connects to it and that
listener may RST. Curl from outside gets a clean response
from the real listener; the agent's WS dial lands on the
stale one and gets RST.

Add ss -tlnp + lsof + systemctl list-sockets to the
diagnostic ladder.
This commit is contained in:
Achmad
2026-06-24 05:43:53 +00:00
parent fc768dbd85
commit b8736f4ac3
1 changed files with 14 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files
DEPLOY.md
+14
View File
@@ -348,3 +348,17 @@ If the journal shows the agent connecting and immediately seeing RST again (a ti
```
Should return HTTP 101 Switching Protocols. If it does, the network is the issue. If it doesn't, the control plane binary has a problem (look at `sdp-control-plane.service` journal for a startup error).
### Still failing after the curl test? Check what's bound to port 3452
The control plane is one listener on port 3452 — if systemd or another process is also bound, the kernel can RST connections to the "wrong" socket. On 186:
```bash
ssh administrator@172.18.139.186
sudo ss -tlnp 'sport = :3452'
sudo lsof -i :3452
sudo systemctl list-sockets --no-legend 2>/dev/null | grep 3452
exit
```
You should see only one listener: `control-plane` PID, IPv6 `*:3452` (dual-stack). If you see anything else — another systemd socket, a leftover container, a proxy — kill it. Then `sudo systemctl restart sdp-control-plane.service` on 186 and try the agent again.