Files
cloudron/questions-v1.md
mrcharles 1267e60e8e feat: apply memory shrink + daemon.json — ground truth update [#731]
11 apps reslidered via API (53.4->29.0GB explicit limits); daemon.json
live-restore + nofile defaults applied (log keys banned: unit flag
conflict — see #731 incident note). perf/apply-memory-shrink.sh codifies
the change. All 159 apps verified running.
Meat: https://projects.knownelement.com/issues/731#note-3929
2026-09-02 19:48:45 -05:00

1.7 KiB

questions-v1.md — KNEL/cloudron open asks (2026-09-02)

Working ask-file for this repo. Answer inline; agent checks before asking again. Version up (v1 → v2...) each round answers land. Fleet-wide asks also live in KNEL/PFVCluster questions-09022206.md.

1. Cloudron API token — unblocks API-first access (asks also in #685/#727)

The #685 investigation ran over raw SSH (root@my.knownelement.com) because no panel API token exists. A token lets the agent use the Cloudron API (apps, configs, backups) instead of shell — cleaner audit trail, and the path for future AWX/Ansible modules.

  • Create an API token (panel: my.knownelement.com → your profile → API access, or cloudron token create via CLI) with read scope at minimum — received 2026-09-02
  • Drop the material value in ~/.creds/cloudron.env as CLOUDRON_API_TOKEN=<token> (never in this repo) — stored 0600; verified: profile → mrcharles, apps list → 200

2. docker daemon.json bounce window (see README "Ground truth")

Applying perf/docker-daemon.json.planned (nofile 262144 default + log rotation + live-restore) requires ONE dockerd restart — every container bounces (~300). live-restore is currently false so there is no zero-downtime path. Until then the postgres nofile bridge is ephemeral (lost on postgres container recreate).

2. docker daemon.json bounce window (see README "Ground truth")

  • Pick a window — founder chose 2026-09-02 ~19:30 CDT (pre-storm). APPLIED: live-restore + default-ulimits nofile 262144 now active; first attempt failed (log-driver flag conflict — unit passes journald), fixed by dropping log keys; see #731 for the incident record.