Shut down SSH master process when leaving tmt
The SSH master process and master socket may nto stay active in sutiations when tmt is invoked multiple times and reusing the guest. Each new invocation will try to start its own SSH master process, with the same socket path, and this new SSH process will be stuck.
Plus, it's simply a resource leak: tmt quits and leaves a SSH process running.
Patch adds a counterpart of wake() methods, suspend(), as in "prepare for quitting, but you may be revisited later". It is a softer version of what finish do - we want to release resources with runtime lifespan, but not all of them.
There is an idea that tmt should split finish into two parts, running finish phases and "cleanup" for taking care of resources. Once that finalizes, the release of SSH master socket should moved into the "cleanup" step, although even there it would need to remain a softer version of the resource cleanup. In other words, the method will probably stay with us, it just would be called from a slightly different part of tmt.
Fixes #3520.
Pull Request Checklist
- [x] implement the feature
- [x] write the documentation
- [x] extend the test coverage
- [ ] include a release note
Also, could you please add a short release note? Thanks!
The SSH master process and master socket may nto
Please run the commit message via codespell, there is a typo here ^ and I believe it would get to the final commit message?
stay active in sutiations
Also here ^
when tmt is invoked multiple times and reusing the guest. Each new invocation will try to start its own SSH master process, with the same socket path, and this new SSH process will be stuck.
Plus, it's simply a resource leak: tmt quits and leaves a SSH process running.
Patch adds a counterpart of
wake()methods,suspend(), as in "prepare for quitting, but you may be revisited later". It is a softer version of what finish do - we want to release resources with runtime lifespan, but not all of them.There is an idea that tmt should split
finishinto two parts, runningfinishphases and "cleanup" for taking care of resources. Once that finalizes, the release of SSH master socket should moved into the "cleanup" step, although even there it would need to remain a softer version of the resource cleanup. In other words, the method will probably stay with us, it just would be called from a slightly different part of tmt.Fixes #3520.
Pull Request Checklist
- [x] implement the feature
- [x] write the documentation
- [ ] extend the test coverage
^ this should be ticked
- [ ] include a release note
Please add a release note, I belive this is a nice bug fix that should be mentioned\
@happz is this ready for re-review? Was the issue with reproducing the test addressed? If not, I would move it back to implemention ? or agree we cannot reasonably test this (what is the least preferred option of course)
@happz is this ready for re-review?
It is not.
Was the issue with reproducing the test addressed?
It was not.
If not, I would move it back to
implemention?
It was moved to implement column 3 weeks ago.
or agree we cannot reasonably test this (what is the least preferred option of course)
I can easily reproduce the issue manually. I cannot reproduce it from a script :/
@happz is this ready for re-review?
It is not.
Was the issue with reproducing the test addressed?
It was not.
If not, I would move it back to
implemention?It was moved to
implementcolumn 3 weeks ago.or agree we cannot reasonably test this (what is the least preferred option of course)
I can easily reproduce the issue manually. I cannot reproduce it from a script :/
I cannot reproduce the issue, stuck session, but I extended the test to at least check for the master process.
Release note added in 319f6151.
/packit retest-failed
Unrelated failure, merging.