fw: make the /srv name worth watching, and say how to supervise it

todo.md said fw daemonizing meant svc could not supervise it, and that
it needed a foreground mode.  Both wrong.

svc has had the shape from the start.  ready=srv: watches the /srv name
rather than the pid, and its own manual says why: "Use this for a
service that posts to /srv and lets the process you started exit, which
many Plan 9 file servers do on purpose.  For these the /srv file is
watched and the process is not, so the process exiting is normal and
never causes a restart."  init.c agrees -- reap() returns early for
Ksrv with that comment on it.

Nor is detaching unusual.  42 commands under /sys/src/cmd use
postmountsrv or threadpostmountsrv; five call srv() directly, and every
one of those is a stdio server (ramfs -i, ext4srv -s, skelfs, hjfs,
wacom) speaking 9P on file descriptors it was handed.  That is not a
foreground service, it is a pipe server: no /srv, no mount, nothing to
supervise.  A foreground mode for fw would buy a pid to watch, and the
/srv name is the better signal -- it survives the process that made it.

What was true underneath the wrong diagnosis: the name was not honest.
Taking the control filesystem away ends the server proc, and the relays
carried on filtering:

	procs: 3 ... take the ctl filesystem away ... procs after: 2
	still filtering? pkt interface: pkt0

A firewall nobody can reach, stop, or notice, and the /srv name gone
while it runs.  Srv.end now takes the whole thing down, which is the
answer the relays already gave when their wire failed.  Same test after:
three procs become none and the interface goes with them.

So: no flag, an example service file in lib/svc, and a SUPERVISION
section in fw(8) that says what init should watch and what restarting
will and will not fix.  Restart=always brings fw back; it does not undo
taking the card, so the new fw has no address to read.  Supervision
works, recovery does not, and that stays open as item 1.

Two checks.  Against the previous fw.c they fail with two orphaned
procs and a pkt interface still bound -- and so do the leak checks at
the end of the run, which is what they were built for.  77 pass.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

1 files changed, 19 insertions, 10 deletions

diff --git a/fw/doc/todo.md b/fw/doc/todo.md
index de5eb8e..d101989 100644
--- a/fw/doc/todo.md
+++ b/fw/doc/todo.md
@@ -4,7 +4,7 @@ Most of this came from code review. Where a finding has been fixed it
 says so; where it has not, it says what is actually true. An item never
 appears in both halves.
 
-`test/fwtest.rc` is a check for every bug that has shipped here — 72 of
+`test/fwtest.rc` is a check for every bug that has shipped here — 77 of
 them now. Run it twice in a row after touching anything.
 
 ## Fixed, first round
@@ -84,6 +84,16 @@ them now. Run it twice in a row after touching anything.
 10. **Promiscuous mode had no filter behind it.** The card must be
     promiscuous for multicast, but every neighbour's unicast was then
     judged, counted and flow-tracked as if it were ours.
+11. **"fw daemonizes, so svc cannot supervise it" was wrong.** `svc`
+    has had the detaching shape from the start: `ready=srv:` watches
+    the `/srv` name, and for those services the process exiting "is
+    normal and never causes a restart". Nothing needed a foreground
+    mode. What was true underneath it: the control filesystem going
+    away ended the server proc and left the relays filtering, so the
+    `/srv` name could be gone while the firewall was still running.
+    Now any part stopping stops all of them, which is what makes the
+    name worth watching. `fwstart` is still the wrong shape; a service
+    file per card is in `lib/svc`.
 
 ## Still open
 
@@ -98,19 +108,18 @@ card is the address that just vanished.
 The cleanup that claimed to handle this was dead code and is gone. The
 answer is not more note handling — it has to be something that outlives
 `fw`, which means the supervisor, with the address stored where `fw`
-does not own it. This also blocks `svc` supervision.
+does not own it.
 
-### 2. fw daemonizes, so svc cannot supervise it
+This is what makes `restart=always` a half-measure rather than an
+answer: `svc` will start `fw` again, and the new one has no address to
+read off a card that no longer has one. It needs `-a`, or the card
+configured again first. Supervision works; recovery does not.
 
-Needs a foreground mode; `ready=srv:name` fits, since `-s` already
-posts to `/srv`. `fwstart` is the wrong shape and should probably go —
-one service per card is the right one.
-
-### 3. One card per fw, and rules cannot name a card
+### 2. One card per fw, and rules cannot name a card
 
 Wants repeatable `-e` and an `ifc=` attribute, together.
 
-### 4. Tflush is not implemented
+### 3. Tflush is not implemented
 
 A request `fw` is blocked on cannot be abandoned. Only affects
 namespace mode, where waiting for an inbound connection is the one
@@ -118,7 +127,7 @@ operation that blocks indefinitely. ~80 lines, with a race that cannot
 be fully closed: between the syscall returning and the handler clearing
 its entry, a note may land on a worker that has moved on.
 
-### 5. Positional `delete n` renumbers
+### 4. Positional `delete n` renumbers
 
 Inherent to positional deletion; iptables has it too. Said out loud
 here rather than fixed.