ssh install ends within a second of a signal while sftp's ssh still connects (closes #57) #58

Merged
clawbot merged 1 commits from issue-57-sftp-sigterm-waitdelay into next 2026-10-04 14:25:48 +02:00
Collaborator

Implements #57, found in #54 (comment).

A SIGINT, SIGTERM or SIGHUP during ssh install now sends sftp a SIGTERM instead of killing it, as ssh to already does for ssh; sftp then stops the ssh it started. The sftp command also has a WaitDelay of a quarter second, so something sftp started that still holds its output no longer keeps the tool waiting: the tool ends with status 1 and removes its working directory.

The test's sftp stand-in no longer uses exec: it starts a child that holds its output before it notes that it has started, and the test now requires the tool to end within a second of the signal, with status 1.

Not visible in the diff:

  • The quarter second runs from the signal. An sftp that has not ended by then is killed outright, as before, and the tool still ends.
  • The WaitDelay also applies when sftp ends on its own; Go then returns exec.ErrWaitDelay for a session that worked.

Disclosure:

  • Judgement call, beyond the brief: session treats exec.ErrWaitDelay as success, with a test of its own. Without it, a run with -v and ControlPersist would report a failure for a key it had added, because the master ssh left running keeps sftp's output open.

Model: opus-5-5

Implements https://git.eeqj.de/sneak/keyfunc/issues/57, found in https://git.eeqj.de/sneak/keyfunc/pulls/54#issuecomment-121965. A SIGINT, SIGTERM or SIGHUP during `ssh install` now sends `sftp` a SIGTERM instead of killing it, as `ssh to` already does for `ssh`; `sftp` then stops the `ssh` it started. The `sftp` command also has a `WaitDelay` of a quarter second, so something `sftp` started that still holds its output no longer keeps the tool waiting: the tool ends with status 1 and removes its working directory. The test's `sftp` stand-in no longer uses `exec`: it starts a child that holds its output before it notes that it has started, and the test now requires the tool to end within a second of the signal, with status 1. Not visible in the diff: - The quarter second runs from the signal. An `sftp` that has not ended by then is killed outright, as before, and the tool still ends. - The `WaitDelay` also applies when `sftp` ends on its own; Go then returns `exec.ErrWaitDelay` for a session that worked. Disclosure: - Judgement call, beyond the brief: `session` treats `exec.ErrWaitDelay` as success, with a test of its own. Without it, a run with `-v` and `ControlPersist` would report a failure for a key it had added, because the master `ssh` left running keeps `sftp`'s output open. Model: opus-5-5
clawbot added the needs-review label 2026-10-04 13:57:29 +02:00
clawbot self-assigned this 2026-10-04 13:57:29 +02:00
clawbot added 1 commit 2026-10-04 13:57:30 +02:00
A signal during ssh install now sends sftp a SIGTERM instead of killing it, so sftp stops the ssh it started, as ssh to already does for ssh. sftp also runs with a WaitDelay of a quarter second, so something it started that still holds its output cannot keep the tool waiting: the tool ends with status 1 and removes its working directory. The test's sftp stand-in now leaves such a child behind, and the test requires that within a second.

Judgement call: a session whose sftp ended well is not failed because something it started still holds its output when the WaitDelay is up, as the master ssh left by ControlPersist under -v does.

Model: opus-5-5
Author
Collaborator

Review passed.

Model: opus-5-5

Review passed. Model: opus-5-5
clawbot merged commit dad29597bd into next 2026-10-04 14:25:48 +02:00
clawbot deleted branch issue-57-sftp-sigterm-waitdelay 2026-10-04 14:25:48 +02:00
Sign in to join this conversation.