New method for unit start that reports whether the launch was successful#14
New method for unit start that reports whether the launch was successful#14
Conversation
majorz
force-pushed
the
start-and-wait
branch
4 times, most recently
from
a9eae31 to
eddb6c6
Compare
Adds a `startAndWait` method in the TypeScript `Unit` class that starts a given unit/service and waits a certain amount of seconds between active state changes to determine and report whether the service start was successful or not. This is implemented in the Rust library as a `unit_start_and_wait` method of the `System` struct. Change-type: minor Signed-off-by: Zahari Petkov <zahari@balena.io>
majorz
force-pushed
the
start-and-wait
branch
from
eddb6c6 to
9e06508
Compare
| # - test the build of the project in a musl containerized environment | ||
| # - provide an install to run integration tests | ||
| # - generate a binary to be published with the package to be used by node-pre-gyp | ||
| FROM alpine:3.20 |
There was a problem hiding this comment.
Why the version bump? This will update to Node 22 and abi v127 which I guess is the right thing as the supervisor is also on v22, but was just curious if you had a specific need for the new version
There was a problem hiding this comment.
I just did this to make the build pass, but this Dockerfile change is not resolved yet at all. Probably we need to install Rust manually with rustup.
There was a problem hiding this comment.
If this builds with alpine:3.21, we can leave it at that as that version also matches what the supervisor is using
| unit.start(mode) | ||
| .await | ||
| .with_context(|| format!("Failed to start unit {unit_path_str}"))?; |
There was a problem hiding this comment.
The only thing that I'm unsure about is that with this implementation there is some disconnection between the current action we are taking and the state of the unit. This call may fail because there is a queued job already for the unit, or perhaps this is queued and the result we get on the active state is the result from a previous operation. Perhaps we could also monitor the Job state until it switches from waiting to running?
I guess it depends on the case, but for something like the OS update it doesn't matter too much who started the update as long as you know that the process is running (even if the request came from a previous job) and have the exec status at the end.
| let wait_duration = Duration::from_secs(wait_interval); | ||
|
|
||
| // Either wait for next active state change event or stop if timeout is reached | ||
| while let Ok(result) = time::timeout(wait_duration, stream.next()).await { |
There was a problem hiding this comment.
Does this always settle? Could stream output results forever causing us to keep waiting?
There was a problem hiding this comment.
I will check this out in more detail to make sure the answer is yes.
|
The progress looks great. It would be good to add some tests as well |
2 participants
Adds a
startAndWaitmethod in the TypeScriptUnitclass that starts a given unit/service and waits a certain amount of seconds between active state changes to determine and report whether the service start was successful or not.This is implemented in the Rust library as a
unit_start_and_waitmethod of theSystemstruct.