docs(notes): measure what logout does, with and without linger

install.sh has always ended by saying the services stop at logout unless
linger is enabled. It now says something that was tested: closing the session
takes down all three units and the nested database with them, and leaves every
one of them running when linger is set.

The first attempt read as a refutation because it used terminate-user, which
ends the user manager whatever linger says. Only terminate-session asks the
question a person leaving their desk asks, and anyone checking their own setup
the other way will conclude linger is broken.

Author: aethrox

docs/notes/2026-08-19-what-is-left.md

@@ -53,11 +53,17 @@ agent once it arrived. It also found that `install.ps1` had been registering
 only the conductor and never the hub, which would have left a first-time
 Windows user with a task reporting `Running` and a dashboard that never loads.
 
-**Reboot survival, and logout on Linux.** A logoff and logon is not a cold boot,
-so Windows still has a reboot to survive. On Linux `WantedBy=default.target`
-stops at logout unless `loginctl enable-linger` is set, which the installer says
-and nobody has tested. Linger is a persistent host change and needs its own
-approval, which is why the installer will not do it on your behalf.
+~~**Logout on Linux.**~~ **Done 2026-08-21**
+([evidence](2026-08-21-logout-and-linger.md)). Closing the session stops every
+unit without linger and leaves all three running with it, which is exactly what
+`install.sh` claims. It also found that `loginctl terminate-user` ends the user
+manager whatever linger says, so anyone testing their own setup that way will
+conclude linger is broken. Linger stays a persistent host change the installer
+will not make on your behalf.
+
+**Reboot survival on Windows.** A logoff and logon is not a cold boot, so
+Windows still has a reboot to survive. It needs a real restart of the machine,
+which is the operator's to give.
 
 Note that nothing starts the Podman machine at logon, and nothing here should:
 it is a machine-wide service rather than Laneward's to register. Both platforms

docs/notes/2026-08-21-logout-and-linger.md

@@ -0,0 +1,80 @@
+# Logout, with and without linger
+
+`install.sh` ends by saying that the services stop at logout unless
+`loginctl enable-linger` is set. It has said that since the first Linux install
+and nobody had tested it, which made it the last documented claim on this
+project resting on nothing but systemd's manual page.
+
+Run on 2026-08-21 at `8bd46ad`, unmodified, in a throwaway Fedora 44 container
+with systemd as PID 1 and no linger enabled by construction, which is the one
+difference from the host the earlier Linux runs used.
+
+## Both halves
+
+A real logind session was opened with `machinectl shell`, all three units
+started inside it, and the **session** closed. The claim holds in both
+directions:
+
+```
+Linger=no    session closed -> user@1000 inactive
+                               laneward-db, laneward, laneward-conductor all gone
+                               no bun processes, /run/user/1000 removed
+
+Linger=yes   session closed -> user@1000 active
+                               all three units active
+                               hub answers HTTP 200 with nobody logged in
+```
+
+The nested database container goes down with the user manager in the first case,
+because Quadlet's unit is a user unit like the others. Nothing survives, and
+nothing is left half-running.
+
+## The trap this run walked into first
+
+The first attempt used `loginctl terminate-user`, and everything stopped **with
+linger enabled**, which read as the claim being false. It is not: `terminate-user`
+ends the user's manager regardless of linger, so it answers a different question
+than a logout does. Only `terminate-session` reproduces what a person leaving
+their desk does.
+
+That is worth knowing beyond this run. An operator who tests their own linger
+setup with `terminate-user`, or a session manager that calls it, will conclude
+that linger does not work.
+
+## The stop is clean
+
+At logout the conductor received `SIGTERM` and logged its hand-back line before
+the unit stopped:
+
+```
+SIGTERM received - stopping 0 running lane(s)
+Stopped laneward-conductor.service - Laneward conductor.
+```
+
+Zero lanes were running, so this does not establish that a lane in flight is
+handed back at logout; it establishes that the same shutdown path D-014 observed
+under an explicit `systemctl --user stop` is the one a logout takes.
+
+One cosmetic thing to expect in the journal, since it looks worse than it is:
+
+```
+bun: error: script "start" was terminated by signal SIGTERM (Polite quit request)
+```
+
+That is bun's run-script wrapper reporting how its child ended, not a failure of
+the unit.
+
+## What this does not establish
+
+- **A lane in flight at logout.** Nothing was running.
+- **A cold boot.** Neither platform has been rebooted. Windows still has that
+  half of the item ([the logon trigger run](2026-08-20-windows-logon-trigger.md)
+  was a logoff and logon, not a boot).
+- **Bare metal.** Same caveat as every Linux run here: real systemd, real
+  podman, shared kernel.
+
+## Cleaned up
+
+The container and its image were removed. Linger was enabled and disabled inside
+that container only; nothing on the Podman machine or the Windows host was
+changed.