Feedback on Mender C++

General Discussions
1

I have been testing the latest version of the Mender C++ client using:

PREFERRED_VERSION_mender = "feature-c++-client-git%"
PREFERRED_VERSION_mender-flash = "master-git%"
SRC_URI:pn-mender = "gitsm://github.com/mendersoftware/mender;protocol=https;branch=feature-c++-client"
SRC_URI:pn-mender-native = "gitsm://github.com/mendersoftware/mender;protocol=https;branch=feature-c++-client"

I have stumbled upon a couple of things, and I thought I would share them.

1. No ‘mender’ in PATH

There does not seem to be anything called mender in PATH anymore, which is instead replaced by mender-auth, mender-flash and mender-update.

This change would break our usage of Mender standalone mode as we run mender commit from scripts/applications.

Possible solution is to symlink mender → mender-update ? Something similar appears to have been done for the mender-client.service which now appears to be linked to mender-authd.service

2. Very long log messages (pedantic)

When inspecting the log of e.g mender-authd with journalctl, the error messages look like this:

Nov 16 12:15:57 eg-e0-dc-a0-65-f2-d9 mender-auth[1191303]: record_id=162 severity=error time="2023-Nov-16 12:15:57.634581" name="Global" msg="Failed to fetch new token: Authentication error: No more servers to try for authentication"

  1. There is a lot of meta data for each message which leads to very long messages, had to zoom out very far (barely readable) to be even close to fitting it to screen. Maybe I should get a bigger screen :slight_smile: .

  2. There are two instances of timestamp meta-data, should probably turn of internal if used with systemd?

3. Bug triggered in code

My device is in a unauthorized state:

Nov 16 12:15:57 eg-e0-dc-a0-65-f2-d9 mender-auth[1191303]: record_id=161 severity=info time="2023-Nov-16 12:15:57.634413" name="Global" msg="Authentication error trying server 'https://eu.hosted.mender.io': Unauthorized error: Authentication error(Unauthorized): Failed to authorize with the server.({"error":"dev auth: unauthorized","request_id":"02d8f668-213d-4604-ab72-6d2ebc78afba"})"

Which leads to the following error message in mender-updated:

Nov 16 11:44:09 eg-e0-dc-a0-65-f2-d9 mender-update[407]: record_id=142 severity=error time="2023-Nov-16 11:44:09.147633" name="Global" msg="Request to check new deployments failed: Assert `auth_data.server_url != ""` in /usr/src/debug/mender/feature-c++-client-gitAUTOINC+e10722e3d9-r0/git/src/api/client.cpp:31 failed. This is a bug."
Nov 16 11:44:09 eg-e0-dc-a0-65-f2-d9 mender-update[407]: record_id=143 severity=error time="2023-Nov-16 11:44:09.147682" name="Global" msg="Error while polling for deployment: Programming error, should not happen: Assert `auth_data.server_url != ""` in /usr/src/debug/mender/feature-c++-client-gitAUTOINC+e10722e3d9-r0/git/src/api/client.cpp:31 failed. This is a bug."

/etc/mender/mender.conf

sudo cat /etc/mender/mender.conf 
{
    "InventoryPollIntervalSeconds": 30,
    "RetryPollIntervalSeconds": 30,
    "ServerURL": "https://eu.hosted.mender.io",
    "TenantToken": "<redacted>",
    "UpdatePollIntervalSeconds": 10
}
2 Likes
2

Thanks so much @mirzak!

3

Hey @mirzak, thanks for testing; nice to see some interest in the new client!

Yes, it would have to be switched to use mender-update commit instead. For scripts, this approach should be pretty safe:

$ mender-update commit || mender commit

The problem with providing a common mender command is that the authentication daemon and the update daemon are now completely separate tools, and it’s not always clear which operation is meant for which. Certain operations overlap, such as mender daemon. Does that mean mender-auth daemon or mender-update daemon? Or both? What if only the former is installed? The semantics here are messy, and we end up pretending that it’s all one service, which it isn’t anymore, so we decided that a clean break is better. And a major version is the only time that we can do that.

The Golang client will still be supported for quite a while, so there is time to fix such issues.

Actually, I think this symlink should not be there. I’ve posted a comment in this ticket, which is where the symlink was introduced, to discuss it.

I suppose that an option to turn log messages into plain messages, without extra log context, would make sense, in order to make command line work easier on the eyes. But it’s not something we consider critical. Pull requests are accepted if you find this important! :smile:

Indeed! Inserted straight into a ticket.

1 Like