Loading today’s stories
Build1 distinct publisher2 min readPublished
A hand-edited link priority parsed as inert text while every status tool reported both links healthy. Pulling the virtual cable was the only check that answered.
The Engineer · Build desk
Compiled by The EngineerSomething wrong?How this is made
The tell was in the data type. With `priority` in the interface blocks, `corosync-cmapctl` returned a single unindexed row, `totem.interface.priority (str) = 10`, while `knet_ping_interval` and `knet_ping_timeout` in the same blocks were already split into `interface.0.*` and `interface.1.*` [6]. With `knet_link_priority`, the same command returned two rows, `interface.0` and `interface.1`, typed `u8` [10]. A string where a number belongs, and one row where there should be two, is corosync telling you it filed your text somewhere it will never be read. The parser was working the whole time; it just had no idea what `priority` was [9].
Only one instrument dissented, and it was a log line rather than a status command: knet kept printing `best link: 0 (pri: 1)` after the config said 10 [7].
The service restart was a hypothesis, not a remedy, and it was billed accordingly: roughly 13 seconds of `Nodes: 1, Quorate: No` on pve-a, with the priority still unindexed afterwards [8]. Set that against the timing the cluster actually runs on. Token is 3125 ms and consensus 3750 ms [14], which is consensus at 1.2 times token [15], and the restart gap is about four token timeouts wide [16]. On a quiet three-node lab that is nothing. With HA-managed guests and fencing armed, that is the window being wagered to test something the `corosync.conf(5)` man page answers for free [9].
The other salvage from the failed attempt is diagnostic. What looked like "sticky" link behaviour, a link refusing to hand over, was not a behaviour at all: the priority had never entered the selection logic, so there was nothing to be sticky about [13]. Two very different faults present identically in the logs, and the only thing that separates them is whether cmap shows the value indexed and typed.
Worth noting what the module promises and does not deliver. The write-up bills an affinity-induced lockup as its second finding [17], and the material stops at the announcement: no rule and no log excerpt to reproduce it. Until that arrives it is an anecdote sitting next to a reproducible result.
One small operational upgrade did survive: `corosync-quorumtool -l` carries the same membership data as `pvecm status` but prints decimal node IDs and hostnames rather than hex like `0x00000001` [18], which is the version you want when correlating IDs against logs by eye.
Ranked by verification strength, evidence, and original report placement.
In week 5 of a Proxmox VE cluster and corosync series, the author combined two topics: defining multiple corosync links and cutting one to prove the other takes over, and testing day-to-day monitoring tools one by one.
A full systemctl restart corosync did not fix the problem: it dropped pve-a out of the cluster for about 13 seconds (Nodes: 1, Quorate: No) and priority remained single and unindexed.
The author frames the module as opening more questions than planned: one strand became hours of investigation caused by a wrong config key, and the other ended in an unexpected lockup discovery, described in the headline as an affinity lockup.
Until this module the cluster had a single corosync link, link1, on the isolated corosync-net network; the author added the management network (192.168.122.x) as link0 by copying /etc/pve/corosync.conf to a .new file, adding ring0_addr to each node and a second interface block to totem, then moving it atomically into place.
corosync-cfgtool -s reported LINK ID 0 at 192.168.122.11 and LINK ID 1 at 10.10.10.11, both with connected status.
With link_mode: passive and equal priorities, the lower-numbered link wins, so the newly added link0 (management network) took corosync's real traffic and the deliberately isolated corosync-net link1 silently became the backup; the log showed 'host: 3 (passive) best link: 0 (pri: 1)'.
Follow any of these and your For You feed starts watching them — no settings page required.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Strong first-hand instrumentation, single reporter
The narrow technical claims are backed by verbatim command invocations and outputs (corosync-cfgtool -s, corosync-cmapctl key listings with types, KNET best-link log lines, virsh domif-setlink, pvecm status), a documented before/after config change, an authoritative cross-check against corosync.conf(5), and internally consistent arithmetic (token 3125 = 3000 + 1x125; consensus 3750 = 1.2x token). What holds the score below the top band is that all of it is one author's nested three-node lab, self-reported, with no independent reproduction and no version matrix.
No adoption signal in supplied sources
The only usage evidence is the author's own three-node lab cluster; the sources contain no deployment counts, release, benchmark, pricing or third-party usage data that would let adoption be scored. Extrapolating ecosystem uptake from one self-reported homelab would be a guess.
Body matches evidence; headline reaches slightly beyond it
The substantive claims are unusually well matched to demonstrated evidence — the author even retracts an earlier 'sticky link' interpretation once the correct key applies — so the core narrative is not inflated. The small positive gap comes from framing: the headline advertises an affinity lockup that the supplied text never documents, and a lab result on one three-node nested cluster is presented as a general lesson about corosync redundancy without version or bare-metal qualification.
Low commercial incentive; audience-building for a personal series
The item is a first-person instalment of a personal learning series on dev.to with no product, sponsor, vendor affiliation or pricing pitch disclosed anywhere in the supplied text, and it publishes its own mistake as the centrepiece. The residual incentive is reputational and engagement-driven — the headline dramatises a lockup and hours-long debugging to draw readers to the series — which is why this is not scored at the floor.
Moderate: detailed but uncorroborated single source
Confidence in the specific mechanism (invalid interface key silently stored unindexed and ignored; knet_link_priority working as documented) is high because the outputs are quoted and self-consistent. Confidence in generality and in the softer figures is moderate: one publisher, one lab, approximate timings ('~13 seconds'), no independent reproduction, no adoption data, and a truncated source body whose headline claim about an affinity lockup cannot be checked.
build
A three-Pi HA control plane that ended up less reliable than the one node it replaced1 distinct publisher
build
Three manual interventions in a month, and every guard was working as designed1 distinct publisher
build
Six MariaDB versions, one real difference: the only reason to leave 10.6 is the July 2026 clock1 distinct publisher
build
Force the tool call, then hand Lightsail a long-lived key1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 25, 2026