Files
command-center/agent/managed-skills/rootless-quadlet-log-retrieval/SKILL.md
T
Frank 4b82f35354 Add blankpad-host auto-learn skills and memory store
Tracked the harness artifacts accumulated on blankpad (blank@), matching
the existing convention for the --home-dank-* memory stores and the 36
already-tracked managed-skills.

managed-skills (9): authentik-proxy-provider-app-link,
dankclaw-guard-chain-layer-diagnosis, e2e-arr-rawip-reachability-triage,
halogen-kv-pool-fit, lan-client-split-dns-fix, noctalia-reference,
rootless-quadlet-log-retrieval, ssh-key-bootstrap-no-sshpass,
swapfile-resize-safe-ordering.

memories (2 stores): --home-blank-.omp-- (dotfiles_git, handy_lifecycle,
input_permissions) and --home-blank-Projects-serverAppConfig--
(frank_large_quadlet).

Secret sweep before staging: no PEM blocks, no credential literals.
Content is fleet topology/IPs only, same class as the tracked dank stores.
2026-09-13 00:25:29 -07:00

2.5 KiB

name, description
name description
rootless-quadlet-log-retrieval Retrieve logs for a rootless Podman Quadlet service on the Dank fleet — which command covers which time window, and the sudo/per-user-storage trap

Rootless Quadlet Log Retrieval (Dank fleet)

Applies to any service deployed as a rootless Quadlet .container unit (frank-large on Dankclaw is the reference case). Rootless storage is per-user, so the deploy user matters more than the container name.

Step 0 — establish ownership before choosing a command

# Which manager owns the unit, and which user runs it?
systemctl --user status <name>.service      # works => rootless user unit
loginctl show-user <user> -p Linger         # Linger=yes => starts at boot

If systemctl --user knows the unit, every subsequent command runs as that user with NO sudo.

Step 1 — pick the log source by time window

Need Command
Current instance, tail podman logs --tail 200 <name>
Current instance, follow podman logs -f <name>
Across restarts/recreates journalctl --user -u <name>.service -n 200 --no-pager
Time-bounded journalctl --user -u <name>.service --since "14:30"
Crash/restart signal only journalctl --user -u <name>.service -p warning
Kernel-side evidence (OOM, SVM) sudo journalctl -k --since ...

Quadlet units commonly run --replace --rm. Consequence: podman logs is destroyed when the container is recreated; the journal captured podman run's stdout and is the only durable record. When the question is "what happened before the last restart", go straight to journalctl --user.

Step 2 — the traps

  • sudo podman logs <name> → Error: no such container. Root's store does not contain rootless containers. Same for sudo podman ps.
  • A system-level journalctl -u <name> returns nothing for a user unit — the -u must be paired with --user.
  • During a first-start weight download, health checks report unhealthy by design. Do not read that as a crash; check whether the payload file is still growing.
  • Vendor verbose switches (e.g. HALOGEN_VERBOSE=1, HALOGEN_DMALLOC_LOG=1) are a config change: they go through git and deploy.sh, never a live env poke on the host.

Step 3 — if you cannot reach the host

No SSH transport is configured on the blank dev box. Do not probe dank@/frank@ and hope. Ask Frank for a key or alias, and label any answer derived only from repo files as not live-verified.