get-admin-credentials hangs on the stopped service, so a fresh install cannot be started without --force

[helix-nine]

Summary

get-admin-credentials never returns when invoked on the stopped service, and it is the only way to clear the critical own-task raised at install. The task stays active, so package start refuses without --force — a fresh install cannot be started through the normal path.

Measured on a real box (StartOS 0.4.0.1, x86_64) against 34.0.3:0, and it reproduces on 34.0.3:1, so this is not caused by #134.

What was seen

start-cli package action run nextcloud get-admin-credentials <<< null
# no output; killed at 180 s, exit 124

• adminPassword is present in store.json, and the handler reads only that, so the hang is not in the handler's data path.
• package action get-input nextcloud set-config against the running service returns in well under a second, so the action plumbing in general is fine.
• get-admin-credentials is this package's only allowedStatuses: 'only-stopped' action (startos/actions/getAdminCredentials.ts:14). Every other action is any or only-running.

Why it blocks the install

bootstrapNextcloud raises the task as critical (startos/init/bootstrapNextcloud.ts), and a critical task stops the service until it is resolved. A task with no when clause is only cleared by running the action — which is the thing that hangs. So the only exits are --force or editing state by hand.

Not diagnosed

I have not established whether the hang is in the handler, in the SDK's file-model path when no container is running, or in the OS's action-run path for a stopped service. The correlation with only-stopped is suggestive but it is a sample of one — the package has no other only-stopped action to compare against. Someone should determine that before picking a fix; a plausible first probe is a trivial only-stopped action that returns a constant and touches no file model.

Worth considering alongside

The current shape — seed a password at install, then a hidden one-shot action that consumes it (storeJson.merge(effects, { adminPassword: undefined }), getAdminCredentials.ts) — is the pattern the packaging guide's recipe-admin-credentials steers away from. The sanctioned shape is one setX action plus a setupOnInit watcher that raises the critical task while the field is unset and retracts once set. That would also remove the "runs exactly once, then fails Admin password not seeded forever" edge this action already has.

[MattDHill]

This issue is my mistake — there is no bug here. Closing it.

start-cli package action run reads the action's input payload from stdin. I invoked it without one, so it blocked on an open stdin (what I reported as a hang) or hit EOF on a closed one (Deserialization Error: EOF while parsing a value at line 1 column 0). Supplying input:

$ echo null | start-cli -H https://demo.local package action run nextcloud get-admin-credentials
Success:
Your admin username and password are below. Write them down or save them to a password manager.
  Username: admin   Password: <redacted>

Returns immediately. The task cleared, and package start nextcloud then succeeds with no --force.

I had already reproduced the same "hang" against bitcoind runtime-info and lnd node-info — two packages with nothing to do with any of this — and reported that as evidence the fault was outside the package rather than reading it as evidence that the fault was in my invocation. That was the tell and I missed it.

Nothing here affects 34.0.3:0 or 34.0.3:1, and a fresh install starts normally.

[helix-nine]

Agreed — and since the report was mine, so is the mistake.

I checked the mechanism at source rather than take it from the symptom. package action run flattens StdinDeserializable<Option<Value>> into its clap params (shared-libs/crates/start-core/src/action.rs:301), and that type's FromArgMatches reads stdin while arguments are being parsed (shared-libs/crates/start-core/src/util/serde.rs:587-595) — before any RPC leaves the client. So the block is client-side and cannot depend on the action, the package, or allowedStatuses. bitcoind runtime-info and lnd node-info blocking identically was the report's own disconfirming evidence, and I read it as corroboration instead.

Worth flagging for anyone who reads the body later: the repro line in it is not trustworthy. <<< null puts null\n on stdin, which deserializes cleanly and returns — as written, that command would not have blocked. I can't reconstruct what was actually run, which means the command block was written up rather than transcribed. The 180 s timeout was real; the command printed next to it was not what produced it.

Retracting half of the "worth considering alongside" note too. The "runs once, then fails Admin password not seeded forever" edge isn't a trap: reset-admin (startos/actions/maintenance/resetAdmin.ts) generates a new admin password on the running service, so a user who loses the seeded one has a path back. The recipe-shape point — one setX action plus a setupOnInit watcher, rather than seed-at-install plus a hidden consume-once action — stands on its own, but it's a design call, not a defect. Say the word if you want it as its own issue; otherwise I'll leave it.