hq/04-ISSUES/228-a-login-the-mesh-set-is-never-given-back/00-report.md

status, opened, located-in, fixed-by, amended-design

status	opened	located-in	fixed-by	amended-design
located	2026-10-04	mesh-host

228 — A login the mesh set is never given back, and undeclaring one stops the node applying

What was observed

2026-10-04. Before the shell module of to-be 38 WP5 was assigned anywhere, a review traced what the host does with the user shape the module declares (the operator account, with the login shell zsh) on three events: first assign, a later push, and unassign.

1. Undeclaring a user stops the node applying anything, for good.

   • The host's removal has no case for a user, so the orphaned record fails with "no way to remove".
   • Orphans are removed before the declaration's first resource, and that failure aborts the apply.
   • The record stays in the host's store, so every later apply fails the same way.

   This was reproduced in a throwaway test against the host's code: the apply produced no outcomes, and an unrelated file in the same declaration was not written. Renaming the resource's id has the same effect. A showcase module carries a user today and is exposed to it too.

2. The shell the account had is never recorded. ADR 0176 §2 says the host "gives back [the login shell] when the holding moves". The host keeps nothing to give back.

3. A login shell is set whether or not it exists. A failed package install does not stop the resources after it. usermod --shell on the distribution only warns about a missing or non-executable shell, and succeeds. The host's read-back compares the user database's string, which matches. So an account can be pointed at a shell that is not there, and console, ssh and display-manager logins then fail. No machine hit this, because zsh was already installed on all four.

Why it matters beyond this instance

Unassigning any module with a login in it, the case the mesh promises is ordinary, wedges the machine's applies until a person edits the host's store. It is the same class of failure as an earlier archive that could not be removed: a shape the host can create and cannot take away.

Located

mesh-host, internal/apply: remove() has no user case, and applyUser neither records the shell it replaced nor checks the shell it sets. The fix is set out in to-be 41 WP1:

• a removal that never deletes an account;
• the login shell given back, if it is still the one the mesh set and the recorded one still exists;
• a shell refused before it is set unless it is executable and listed among the machine's shells (a shell that refuses logins need only be executable, since the distribution does not list it and the controller's own account uses one).