1.9 KiB
| id | status | status_updated | status_note | component | severity | timestamp | last_seen | occurrences | files | tags | related | fix_commits | legacy | gitea_issue | gitea_synced_status | gitea_synced_hash | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| bug-1865 | fixed | 2026-09-25 | 910b43cd; soaks 2026-09-25 (2 chaotic + 1 sequential) fdatasync_failed=0, all PASS |
controller | unknown | 2026-09-25T14:43:27Z | 2026-09-25T14:43:27Z | 1 |
|
|
|
true | 284 | fixed | 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