I understood that, the mender have logs and we can pipe/grep the logs to get the required data.
But, this is not something recommended to use in our project
Hence, I would like to know, how to get the update progress from mender client in standalone mode? Whether I can get the progress via a state script? Should I edit the mender client source to get the progress directly to a file (or some global variable which can pass the progress data to C application)?
Apart from progress, we also need to get the update/fail/rollback status via better API calls which do not have these logs grepping and parsing method.
Hence, I would like to know, how to get the update progress from mender client in standalone mode?
There is currently no IPC mechanism to get the progress of download state and you can not get this information using state-scripts.
So you would need to change the code, to provide an interface to this information, e.g exposing an HTTP server, or implement D-bus, raw unix sockets or files and there are probably other options as well.
Apart from progress, we also need to get the update/fail/rollback status via better API calls which do not have these logs grepping and parsing method.
It seems that this can be done āoutsideā of Mender, or using state-scripts to some expect and only for the 2.0 version.
@mirzak, May I know how you use the d-bus example with mender? Are you passing the state information from Mender client to Qt GUI? I didnāt get the complete picture by just seeing the scripts so asked
Actually @texierp, has created these scripts so he can best answer that
Are you passing the state information from Mender client to Qt GUI?
But I think this is a correct understanding, but these can be easily modified to pass the information to non Qt apps as well as long they can interface with D-bus.
@ajithpv, Yes youāre right, The main idea is to be able to manage the full update process via a simple graphical interface with Qt (QML) for instance (retry later, validation and so on). You can find a very basic implementation (without the GUI), for sure, Iāll try to publish the rest of the project (a little cleaning before ).
As Mirza said, with D-Bus you can work with an another framework. For a generic approach (C/C++), it is possible to use sd-bus also.
The use case to get the current state of the daemon seems quite common.
It would be nice to have an API to get it through one of the several available IPC like D-Bus or HTTP server.
But by looking at the source code, it does not seem easy to get the state because during a standalone update, the daemon does not seem to be aware of the process actually.
My real issue is that the state-scripts only handle transitions but if the client, say a GUI, is not ready at the right moment, the information is lost.
Do you have any though of a possible and preferable solution that one could try to implement?
AFAIK, standalone have a different code flow and is not calling any daemon logic inside the standalone (except calling mender daemon command option).
You can use the D-Bus to get the state transitions from the statescripts to another application (say a GUI on the client) as how @texierp done.
But, the real problem comes when you need to get more detailed information on the update (say, why the update has failed or what is the current progress of streaming etc.). This required the mender client modification. When I see the source, all these cases are handling with the if-else methods and one need to check all these cases and transfer the information to outside world.
One more catch is that, if you are using the IPC, then you will not get the previous state after the reboot (reboot can happen due to various reasons). Hence, currently, I stick to a file write approach where the file is stored outside filesystem (Ex: data partition). In this way, any application can read and get the status and progress at anytime (even if the mender standalone is not running).
Just a note, that this has changed slightly with the release of 2.x.x, where the standalone mode does share more of the code with managed mode. e.g the 2.x.x Mender client will call state-scripts in standalone mode as well (not all states but some of them), list of states can be found here,
Whether I will get what kind of error (when it failed to update the system) from the ArtifactFailure script? Iām just curious to know whether the state script gives the high level transitions (from one state to another) alone or will give more details of a particular state (errors, progress etc)
You can run mender -commit unconditionally. The Mender client will know if there is something to commit or not, it also has a specific return code if there was nothing to commit.
"Commit current Artifact. Returns (2) if no update in progress"
Ok, that is interested @mirzak, thank you. But in my case I would prefer a manual action on the web gui to commit.
I am working on a headless system (robotics), so if I messed up the network settings in an update, I wonāt be able to connect to the board anymore. Then, if I can access the web based UI, it would means that the network is available. If not, on next reboot, there would be a rollback so I can connect and send a new update.
So the issue remains. How could the UI could know that there is a āpending commitā or a rollback occurred?
Maybe using the fork I have mentioned?
Do you think that this change could be added to the upstream project?
I didnāt get the exact use case. But, the mentioned fork also performing command line check for commit right (instead of a web UI)?
What @mirzak mentioned also perform the same from the command line. If the return value is 2 then you can confirm that, there is no update in progress or artifact performed commit. Else, it will commit the current artifact.
Here, you can perform mender -commit from the standalone without worrying because, this command will not be having any side affects even if we do it more than once.
My issue is that I do not want to commit automatically on reboot and I would like to show a āCommitā button on the web UI only if an upgrade is pending and not always.
Update progress and Status update on Client side will be a great feature if it can be introduced in the Client side itself. Here is a suggestion I would like to offer:
Possibility of converting the client to locally communicate with other processes using a pubsub model. Using implementations like gRPC, JSON-RPC, WAMP-protocol and the likes can help achieve this.
Because even embedded devices have various other services running and therefore scenarios for, when an update should be performed, can be contextually set by the end user. So,these services can make the mender client aware about when to perform updates rather the Mender client itself taking the load to keep polling and go heavy on the server.
This will also hopefully eliminate the need for polling mechanism and reduce load on the server too.
Eg: In automative sector, if mender client is running on the edge device, then the implementer can set specific scenarios as to when to perform an update or probably even delegate the update to the end User.
The current implementation seems to put lot of pressure on the server end and the entity running and maintaining the Server using a remote deployment approach, rather if the initiation of update can be delegated at the client end then it can help simply the process a little by little.
Regarding control (e.g. trigger check for update, delay update, etc.) there are 1) state scripts and 2) CLI interfaces (e.g. mender -check-update, mender -send-inventory, mender -commit), did you check out those?
However it might make sense to consider more complex use cases for controlling the client in the progress reporting ticket above, so that it is designed as a client-side API that can be extended. Of course then weād need to worry about security, authentication, etc. as well so it grows more complex.
).