---
id: "bug-1865"
status: "fixed"
status_updated: "2026-09-25"
status_note: "910b43cd; soaks 2026-09-25 (2 chaotic + 1 sequential) fdatasync_failed=0, all PASS"
component: "controller"
severity: "unknown"
timestamp: "2026-09-25T14:43:27Z"
last_seen: "2026-09-25T14:43:27Z"
occurrences: 1
files: ["src/controller/ha.c", "src/controller/config_repl.c"]
tags: ["controller", "ha", "fd", "double-close", "persist", "wal", "durability"]
related: []
fix_commits: ["910b43cd"]
legacy: true
gitea_issue: 284
gitea_synced_status: "fixed"
gitea_synced_hash: "58c6f7bbb4e0"
---

# bug-1865: Standby's WAL fd closed out from under it at failover: chaotic HA soak 2026-09-25 (ha-chaos-o1)…

## Description
Standby's WAL fd closed out from under it at failover: chaotic HA soak 2026-09-25 (ha-chaos-o1), ctrl-3 at 14:39:55.574 'liveness poll: no primary activity for 11s -> failover' / 'primary_ctrl_fd RDHUP', and 3 ms later 'flusher fallback fdatasync FAILED (errno=9 Bad file descriptor) -- durable_lsn held at 90', then errno=22 EINVAL once the number was reused by a socket; 2305 fdatasync failures, durable_lsn stuck; soak still PASSed (counted as excluded bug924) but one round's jobsub failed EIO.

## Environment
_Not recorded (migrated from buglog.json)._

## Reproduction
_Not recorded (migrated from buglog.json)._

## Root cause
config_repl.c:2192 stores the netio endpoint's raw fd (c->ha.primary_ctrl_fd = ep->fd) and ha_on_primary_ctrl_fd_rdhup (ha.c:8648, three branches) later close()s it directly. netio owns that socket and closes it on endpoint teardown, so by then the number may have been reused -- here by the standby's WAL segment (lowest free fd) -- and HA's close() closes the WAL instead. Double close / stale fd. Once a socket takes the number, WAL fdatasync gets EINVAL and pwrite could write WAL bytes into a socket.

## Fix
_Not recorded (migrated from buglog.json)._

## Verification
_Not recorded (migrated from buglog.json)._

## References
- Gitea: #284