I wanted a way to include a user approval step in the middle of the update with the scarthgap update. Previously with the kirkstone, I had,
This worked out fine, since with exit 1 mender didn’t abort the deployment. But turns out I was relying on a bug in mender for this flow. With the scarthgap update, it got changed and exit 1 aborted the deployment. So to temporarily work around that I just changed the exit 1 to exit 21 and set the retry interval of 60s.
Now the script loops every 60s, till the user approves, which is not ideal. Also on the downside, if user approves and the application is closed within that 60s while keeping the system running, this would not pass and the user would need to approve it again. Since the state script needs to communicate with the user software for approval.
I was looking for a way to pause the update after downloading and update_control_map came up. But looking at the docs, this was deprecated on v4 of the client.
Also I am not sure, for how long a deployment can stay in a pending state.
In short, I am trying to implement a update flow where the user can indefinitely postpone the updates without the deployment getting errored out.
The one approach I have in my mind right now is,
- remove the current state scripts and disable mender-updated
- poll from my software if there is a deployment available
- prompt user and start mender-updated service on yes
I can see 2 problems with this approach once the previously mentioned how long can a deployment is allowed to be stuck in pending. And second, stopping the mender-updated service means I have no access to the remote terminal, although not necessary, it would be handy to have it available at all times.
Hi @hellozee,
For really indefinitely postponing a deployment, the approach you mentioned is the only one that I am aware of. When mender-updated has started to receive one, I think the limit is at 24h for postponing.
However you won’t lose the remote terminal with Mender Client 4. The Client has been split into mender-authd and mender-updated, so you can just keep mender-authd running for mender-connect, and start mender-updated whenever required. I haven tried it, but should work as far as I can tell.
If you create a proof of concept for the update polling and eventual starting of mender-updated, I think it would be very useful to others sharing the same problem too!
Greetz,
Josef
1 Like
I manually disabled the mender-updated service and upon reboot, I didn’t have access to the remote terminal anymore. And I did verify both mender-authd (v4.0.6) and mender-connect (v2.3.0) is running.
Feels like I may be doing something wrong here, cause the docs also say I just need mender-connect configured and running alongside mender-auth.
Hi @hellozee,
Can you check the logs of mender-connect like this, maybe we can see what’s going on?
journalctl -u mender-connect
Greetz,
Josef
With that I got,
systemd[1]: Started Mender Connect service.
mender-connect[1077]: time="2025-02-27T10:10:58Z" level=info msg="Loaded configuration file: /etc/mender/mender-connect.conf"
mender-connect[1077]: time="2025-02-27T10:10:58Z" level=warning msg="ShellArguments is empty, defaulting to [--login]"
Also, I noticed if I start the mender-updated service and stopped it after making a successful connection, I can still access the remote terminal from Web UI.
Hi @hellozee,
So I understand correctly:
- if you don’t start
mender-updated, then the remote terminal never gets functional
- if you start
mender-updated, and then stop mender-updated again, the remote terminal works and continues to be functional
Is that right?
So what if, with all units disabled, you do this?
systemctl start mender-auth
systemctl start mender-connect
That should really be everything you need for the remote terminal.
Greetz,
Josef
So what if, with all units disabled, you do this?
systemctl start mender-auth
systemctl start mender-connect
That should really be everything you need for the remote terminal.
I expected this too, but seems like it is not working for some reason. Interestingly the “Last activity” doesn’t get updated either on the UI.
Now that’s expected, as this is triggered by inventory updates. But I wonder why the remote terminal isn’t showing up. 
Greetz,
Josef
Ok found something, I was thinking to call the connect api endpoint but when tried to do a GetJwtToken, it returned empty. So subsequently, I did a FetchJwtToken, it fetched the token from the server and also at the same time the remote terminal became available. Playing with it a couple more times, that FetchJwtToken call is enough to start the connection, which again feels strange. I was expecting starting mender-auth would automatically call that endpoint. But regardless there is way to make this work now.
@hellozee not sure I can follow. So you need to start mender-authd, then manually call the FetchJwtToken, and then mender-connect works? That’s definitely unexpected. Let me see what I can find out.
Greetz,
Josef
Yes, it also works if I start mender-authd & mender-connect and then call FetchJwtToken.
Also I have come up with a little proof of concept but I keep on getting “Device Provided conflicting request data” on the server,
import requests
import pprint
import dbus
system_bus = dbus.SystemBus()
auth = system_bus.get_object("io.mender.AuthenticationManager", "/io/mender/AuthenticationManager")
auth_interface = dbus.Interface(auth, dbus_interface="io.mender.Authentication1")
token, _ = auth_interface.GetJwtToken()
headers = {
'Accept': 'application/json',
'Authorization': f"Bearer {token}"
}
current_artifact = "<name from `mender-update show-artifact`>"
r = requests.get("https://eu.hosted.mender.io/api/devices/v1/deployments/device/deployments/next",
params = {
"artifact_name": current_artifact, "device_type": "intel-corei7-64"
},
headers = headers,
)
if r.status_code != 200:
print(f"No update found! Got status code {r.status_code}")
exit(0)
# insert user confirmation code here
print("Updating to", r.json()["artifact"]["artifact_name"])
systemd = system_bus.get_object("org.freedesktop.systemd1", "/org/freedesktop/systemd1")
systemd_interface = dbus.Interface(systemd, dbus_interface="org.freedesktop.systemd1.Manager")
systemd_interface.StartUnit("mender-updated.service", "replace")
I feel like I making some mistake while calling mender API, cause if I don’t call the mender API, the update goes thru fine.
