[RFC PATCH 0/3] Sticky FAILURE State

7 views
Skip to first unread message

Konrad Schwarz

unread,
Apr 11, 2026, 3:46:30 PM (11 days ago) Apr 11
to swup...@googlegroups.com, Konrad Schwarz
From: Konrad Schwarz <konrad....@siemens.com>

The swupdate-progress interface defines a message
who's key field is a field "state".
Intuitively, this field would represent the
current state of the update state machine.

In practice however, a few state=PROGRESS messages follow a
state=FAILURE message.

This is surprising to progress monitors, since the state
of the update attempt is still (or should be) FAILURE and not
(update-in-) PROGRESS.

Progress monitors that wish to indicate the current
state need to track the messages and implement
a (little) state machine to make sure they remain
in FAILURE state until the next status=START message.

The following change integrates that state machine into
the core progress thread, which
will simplify logic in progress monitors.

This change affects the standard tools/swupdate-progress monitor.

tools/swupdate-progress is able to trigger certain events when
reaching FAILURE (or SUCCESS).
With the above change, such events would be
triggered several times, once for each message with state FAILURE.
One event option is a user-defined "post script".

To prevent this, the second patch adds "edge filtering"
to tools/swupdate-progress, so that events
are triggered only on the transition to FAILURE.

Since this is in some sense an incompatible change,
the final patch bumps the message API patch level.

Konrad Schwarz (3):
swupdate-progress: make FAILURE state sticky
tools/swupdate-progress: sticky FAILURE state modifications
swupdate-progress: indicate modified API

core/progress_thread.c | 16 ++++++++++++++++
include/progress_ipc.h | 2 +-
tools/swupdate-progress.c | 11 ++++++++++-
3 files changed, 27 insertions(+), 2 deletions(-)

--
2.47.3

Konrad Schwarz

unread,
Apr 11, 2026, 3:46:30 PM (11 days ago) Apr 11
to swup...@googlegroups.com, Konrad Schwarz
From: Konrad Schwarz <konrad....@siemens.com>

Turn all status=PROGRESS progress messages after a status=FAILURE message
into further status=FAILURE messages until the next status=START
message.

Signed-off-by: Konrad Schwarz <konrad....@siemens.com>
---
core/progress_thread.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)

diff --git a/core/progress_thread.c b/core/progress_thread.c
index f3ab0dda..3d413aef 100644
--- a/core/progress_thread.c
+++ b/core/progress_thread.c
@@ -53,6 +53,8 @@ struct swupdate_progress {
struct connections conns;
pthread_mutex_t lock;
bool step_running;
+ bool in_failure_state;
+
};
static struct swupdate_progress progress;

@@ -81,6 +83,20 @@ static void send_progress_msg(void)
const int maxAttempts = 5;

pprog->msg.apiversion = PROGRESS_API_VERSION;
+
+ switch (pprog->msg.status) {
+ case START:
+ pprog->in_failure_state = false;
+ break;
+ case FAILURE:
+ pprog->in_failure_state = true;
+ break;
+ case PROGRESS:
+ if (pprog->in_failure_state)
+ pprog->msg.status = FAILURE;
+ break;
+ }
+
SIMPLEQ_FOREACH_SAFE(conn, &pprog->conns, next, tmp) {
buf = &pprog->msg;
count = sizeof(pprog->msg);
--
2.47.3

Reply all
Reply to author
Forward
0 new messages