Skip to content

truenas-appliance-runner: read node B's ids in the call that sees its new boot, not in a later one sshd may refuse - #25

Merged
william-gr merged 1 commit into
masterfrom
ha-ids-with-boot
Oct 19, 2026
Merged

william-gr merged 1 commit into
masterfrom
ha-ids-with-boot

Conversation

@william-gr

Copy link
Copy Markdown
Contributor

Why

#24 made unique() wait until node B answers SSH from a new boot after its reboot. webui run 39296815434 still failed at the same step:

  • The new wait saw B's new boot over SSH.
  • It then waited for B's API.
  • It then read B's IDs in a separate SSH call, which was refused: ssh: connect to host 10.231.0.12 port 22: Connection refused.

So sshd answering once does not mean it stays up. SSH on the nodes is enabled through middleware (tnctl enable-ssh), and middleware applying its SSH settings as it starts most likely restarts sshd. That cause is a reading, not confirmed.

Change

The loop's SSH call now returns B's boot id and its machine-id and hostid together. The call that sees the new boot also yields the IDs, so nothing depends on sshd staying up afterwards. The API wait still follows, and it does not use SSH.

Testing

  • shellcheck -x appliance.sh ha.sh lib.sh (the CI command) passes.
  • The loop was run locally against a fake ssh_: refused twice, then the old boot, then a new boot. It kept waiting, took the new boot id and the IDs from that one call, and the "still has A's ids" check passed.

… new boot, not in a later one sshd may refuse
Comment on lines +245 to +247
# B's ids are read in the same call that sees the new boot, not in another
# one after it: sshd answering once does not mean it stays up. Middleware
# applies its own SSH settings as it starts and restarts sshd, and in run

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LOW — This comment states as fact that middleware "restarts sshd", but the PR description calls that cause a reading, not confirmed. The code doesn't depend on which cause it is, but these comments are where the repo records why things are the way they are. Something like "most likely restarts sshd" would keep the record accurate if the real cause turns out to be different.

@github-actions

Copy link
Copy Markdown

One finding: one LOW. No human review needed.

The change reads node B's boot id, machine-id and hostid in one SSH call, so the call that sees the new boot also returns the IDs. That removes the later ids b call, which is the one that was refused in run 39296815434. How the output is split:

  • now="${out%% *}" is the boot id. It is empty when SSH fails, because || out= clears out, so the loop keeps waiting.
  • b="${out#* }" is "<machine-id> <hostid>", the same format ids() returns. The [ "$a" != "$b" ] comparison with A's IDs therefore still compares like with like.
  • The IDs are now read before the API wait instead of after it. They don't change within a boot, so the result is the same.

LOW — the new comment at ha.sh:245-247 states the middleware-restarts-sshd cause as fact, while the PR description says it is unconfirmed (inline).

Separately, check-ticket is failing because the PR title has no ticket reference. That comes from the title, not the code.

@github-actions github-actions Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Approved. 1 finding(s): 1 LOW.

Nothing blocks and no human review is needed.

@william-gr
william-gr merged commit 60457b2 into master Oct 19, 2026
7 of 8 checks passed
@william-gr
william-gr deleted the ha-ids-with-boot branch October 19, 2026 18:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant