rajames/LithosAnanke
1
1
Fork 0
Code Issues 54 Pull Requests 1 Actions Packages Projects 1 Releases 6 Activity

demo: one core for all sessions, lowest priority, 1 GiB; Try it deployed [skip ci]

Browse Source 
An idle StarshipOS guest keeps a host core 100% busy (measured 2026-11-08:
QEMU at 100% of a core, 148 MiB, the guest idle at its prompt; #151).
starshipos-demo.service: CPUQuota=100% and Nice=19 for all sessions
together, MemoryMax=1G -- sized for this server, where the old 300% and 4G
let two visitors starve both wikis and Gitea. DEPLOY.md says how to apply
it. FABRIC-3 XLVIII.4: Try it deployed and checked from outside; the ttyd
package's own login service; #151, #152.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01GE3SDvQn5EoxdGufk84zz2
This commit is contained in:
Claude
2026-11-08 00:38:54 +00:00
parent 4d0b9ab771
commit 88b962b29e
3 changed files with 30 additions and 3 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/fabric/FABRIC-3.md
+17
View File
@@ -6243,3 +6243,20 @@ review list begun meanwhile goes to the milestone v4.0.0-alpha.4.
- With both wikis up again (Shenandoah, the .com's heap at 512 MiB, the .org's given 256 more): the
server at 2.6 of 3.8 GiB used, 1.2 GiB available, 2 GiB of swap used; Build 204 (three images, the
v4 tests) passed alongside them.
### 4. Try it, deployed (2026-11-08)
Captain Bob ran `demo/DEPLOY.md` on the server (#115): try.starshipos-f18.com with its own Let's
Encrypt certificate, ttyd behind Apache, framing allowed to the .com alone. Checked from outside: a
session ready 1.5 s after the page opens, `3 4 + .` -> `7 ok`, `: SQUARE DUP * ; 7 SQUARE .` ->
`49 ok`, a third visitor at once told every machine is busy.
Found on the way:
- Ubuntu's `ttyd` package starts its own `ttyd.service` -- `login` on port 7681, ours -- and
until it was disabled the page served the server's login prompt to anyone. `DEPLOY.md` step 4
now disables it first and checks what listens on 7681.
- **An idle StarshipOS keeps a host core 100% busy** (#151): the demo machine at its prompt, idle
20 s, QEMU at 100% of a core, 148 MiB resident -- the kernel's idle loop polls, never halts. Two
visitors' sessions with Gitea's diff statistics on a burst of pushes (#152, 1.75 GiB) filled the
server's swap and stalled both wikis. The service now caps all sessions together at one core at
the lowest priority (`CPUQuota=100%`, `Nice=19`, `MemoryMax=1G`), until #151 is fixed.