v0.63.0 — the bridge was there all along

moshcode dns status has been telling people their bridge was down while it was up, and then handing them the one command that would actually take it down.

What it looked like

A machine running the bridge as a systemd unit, resolving Moshpit names perfectly, forwarding everything else:

platform   linux
bridge     not running
routing    configured (/etc/systemd/resolved.conf.d/moshpit.conf)

! routing is in place but the bridge is not running — Moshpit names will fail.
  fix with: sudo moshcode dns enable     undo with: sudo moshcode dns disable

Every line of that alarm is false, and the remedy is worse than the complaint. dns enable starts a bridge bound to 127.0.0.1:5354, while the one already working holds 0.0.0.0:5354. The kernel delivers to the more specific socket, so the healthy bridge stops receiving anything at all — running, supervised, and deaf. Catch-all routing means that is not a Moshpit outage, it is the machine's whole resolver. portHolder has carried a comment about this failure for a while ("that took DNS down twice in one day"); what was missing is that status was the thing walking people into it.

Why it said that

status asked its own pidfile and nothing else. That file describes a bridge this tool started, in this privilege context — and nothing else qualifies:

• a bridge run as a systemd unit
• a bridge started by hand with dns start
• a bridge started by dns enable itself, which escalates to root and therefore wrote its pidfile under root's HOME instead of the invoking user's runtime dir

The third is the sharp one. dns enable is the supported way to start a bridge, and it recorded that bridge somewhere every later unprivileged dns status and dns disable would neither look at nor be allowed to read. The tool lost track of its own daemon the moment it succeeded.

What changed

The port gets asked. bridgePresence puts both questions, because they fail differently — a resolver that stopped answering Moshpit names loses a namespace, and one that stopped forwarding takes the box off the internet:

platform   linux
bridge     answering on 127.0.0.1:5354 (pid 1330, bun) — started by something other than `dns enable`
routing    configured (/etc/systemd/resolved.conf.d/moshpit.conf)
registry   reachable — 17848 TLDs claimed

A bridge nothing here started is reported as a bridge, with its pid, so it can be found. The alarm now fires on nothing answers, not our pidfile is empty. And a new warning covers the state that was invisible from the Moshpit side entirely: a bridge that answers names but has stopped forwarding, which is the one that costs you clearnet.

The advice lost its sudo too. The CLI escalates the single step that needs root; teaching sudo moshcode as a habit is how sudo moshcode update ends up reinstalling the whole tool into /root.

Two supporting fixes came with it. pidfilePath honours SUDO_UID, so an escalated enable records the bridge where the unprivileged runs that ask about it will actually look — and only when that runtime dir exists, since deriving /run/user/<uid> on a machine without one swaps an unreadable path for a missing one. And status now uses the injected registry client like every other caller, which had quietly made it the one subcommand that could not be tested without a network.

Note

bridge not running was never a reason on its own to run dns enable. If you hit this and enabled on top of a working bridge, check for two listeners on 5354 — ss -lnup | grep 5354 — and stop the one you did not mean to start.