Give box-firewall.service RemainAfterExit so its state means something

Found by running the drill on a real host, which I could not do before.

The unit is Type=oneshot with no RemainAfterExit, so systemd marks it
'inactive (dead)' the moment ExecStart succeeds. The rules are applied and the
box-to-box drop is live, and the unit still reads as though it died. That is
precisely the question people ask this unit: drill.sh's own failure hint sends
you to 'systemctl status box-firewall.service' to find out whether the firewall
came up, and today the honest answer and the alarming one look identical.

setup-host.sh already believed this was set — 'The unit is RemainAfterExit, so
once it has run it stays "active" forever' — and reasoned from it to explain why
it uses restart instead of 'enable --now'. The reasoning is right and the
restart is right; only the unit was missing the line the comment assumed.

Verified live: before, 'nft list table bridge box' showed the drop present while
is-active said inactive. After, is-active says active (exited) with the drop
still present, and restart still re-applies.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
claude-bot-andresmgsl 2026-07-17 14:05:23 +00:00
parent 3e1143f1d3
commit 043e556027
2 changed files with 16 additions and 0 deletions

View file

@ -28,6 +28,15 @@ which records not just what changed but what each drill run proved.
`sudo install.sh` it would have added `root` to the group: a no-op (UID 0 `sudo install.sh` it would have added `root` to the group: a no-op (UID 0
opens the socket regardless) that also left the actual user locked out of opens the socket regardless) that also left the actual user locked out of
their own boxes. It now derives the login user from `SUDO_USER`. their own boxes. It now derives the login user from `SUDO_USER`.
- **`box-firewall.service` now reports its state honestly** — the unit is
`Type=oneshot` and was missing `RemainAfterExit=yes`, so it went
`inactive (dead)` the instant it succeeded: a host whose isolation was
perfectly live read as one whose firewall unit had died. drill.sh sends you
to `systemctl status box-firewall` to diagnose exactly that, and
setup-host.sh's own comment already asserted the unit "is RemainAfterExit" —
it was not. Found by running the drill on a real host and mistrusting the
green: `nft list table bridge box` showed the drop live while the unit read
dead. `restart` was and remains correct either way.
- **`setup-host`'s apt calls can no longer hang** — a fresh cloud image has - **`setup-host`'s apt calls can no longer hang** — a fresh cloud image has
`apt-daily`/`unattended-upgrades` holding the dpkg lock, and a plain `apt-daily`/`unattended-upgrades` holding the dpkg lock, and a plain
`apt-get install` waits on it silently and indefinitely. Now bounded `apt-get install` waits on it silently and indefinitely. Now bounded

View file

@ -6,6 +6,13 @@ Wants=network.target
[Service] [Service]
Type=oneshot Type=oneshot
# The unit's state must mean "the rules are applied", because that is the
# question everyone asks it — drill.sh sends you to 'systemctl status
# box-firewall' to diagnose exactly that. Without this, a oneshot goes
# 'inactive (dead)' the moment it succeeds, so a host whose isolation is
# perfectly live reads as a host whose firewall unit died. setup-host.sh's
# comment already assumed this was set; it was not.
RemainAfterExit=yes
ExecStart=/usr/local/sbin/box-firewall ExecStart=/usr/local/sbin/box-firewall
[Install] [Install]