Secure Offline Updates Logs in Journalctl: Access from Docker container?

Technical Support
, , , ,
1

Hi Toradex Community,

I’ve been working on a feature to create a user-friendly UI to help user monitor if our application is being updated via Secure Offline Updates.

Here’s the scenario: as we know, Secure Offline Updates currently logs information into the journalctl of the host image. Performing a journalctl -q -u aktualizr* allows to monitor progress via command line.

I am now implementing a function in my C++ application that will monitor this output every few seconds and display a popup once something among the lines of “Update available. Acquiring lock box” displays in the journalctl. This will be helpful as new updates will be deployed by non-software people carrying USB lockboxes.

However, I realized that Secure Offline Updates logs it in the journalctl of the host image, and that there is no journalctl in the docker container.

Is there something we can do to manage to read the journalctl outputs of Secure Offline Updates from our application container?

Thanks in advance!
Anthony

2

Greetings @anthonyabboud,

Just to make sure I understand your use-case. You basically want a way to detect when an offline update is starting/about to start, correct?

If that is the case, maybe trying to parse the journald logs from within a container is more involved than required. I’m not sure at the moment how to get the journald logs inside the container but I’m sure it’s possible, in which case your method would work. But perhaps some alternative methods are worth considering.

For example, if you’re using offline updates then the update starts within ~1sec of the lockbox being available. Couldn’t you bind-mount the lockbox path into your monitoring container, then just monitor when the lockbox becomes available. Since once it’s available the offline update will soon start shortly afterwards.

Or another idea, have a script on the host outside of the container that parses the logs. Then once the key log line is detected by the script it creates a file. The path where this file exists could be bind-mounted into your monitoring container. Then your logic in the container just detects when this file is available, which means your script outside of the container detected the log line.

Now your idea could work, but we’ll need to figure out how to get journald logs available inside a container. This would probably involve giving the container some extra permissions/access to the host system. Which may be undesirable, unless you have to use this method for some reason.

Best Regards,
Jeremias

3

Hi @jeremias.tx ,

Just to make sure I understand your use-case. You basically want a way to detect when an offline update is starting/about to start, correct?

Yes, that is correct. Then, if I’m able to do this, I’d like to also attempt implementing a failure popup if, for example, the user accidentally disconnects the USB drive during update or if the update itself fails.

Couldn’t you bind-mount the lockbox path into your monitoring container, then just monitor when the lockbox becomes available.

I could do that, but that would probably create a vulnerability to my application if someone creates an empty ‘update’ folder with their own USB drive, which would trigger the update popup even though nothing’s going on.

Or another idea, have a script on the host outside of the container that parses the logs. Then once the key log line is detected by the script it creates a file. The path where this file exists could be bind-mounted into your monitoring container. Then your logic in the container just detects when this file is available, which means your script outside of the container detected the log line.

That’s an idea! I’ll try out a prototype and see if it satisfies my needs. I’d need to store this script in a bind-mounted folder and see if executing it from the container side will allow it to fetch from the journal on the host side.

This would probably involve giving the container some extra permissions/access to the host system.

My container already requires root privileges since I need to manually change/access the hardware clock. But making the journald logs available to the container seems like uncharted territory for the moment so I prefer the previous suggestion for now.

I will report back once I try some of your suggestions.

Thanks!

4

I’m curious to hear about your findings.

Additionally, just to let you know we also have in our backlog to one day figure out this limitation with offline updates and how they give very little feedback outside of parsing the logs directly. Though I don’t have any tangible information or timeline for this, just wanted to let you know that you’re not alone in this. Hopefully in the future we can provide something more robust and built-in regarding offline update status.

Best Regards,
Jeremias

1 Like
5

Hi,
Just stumbled upon the same question and wanted to know if there’s a different way in the mean time to get feedback from an offline update other than parsing the logs?
We have cases where the offline update cannot be applied (e.g. because of lockbox expiration, wrong system time, …) and we’re almost blind.

Thanks,
Lukas

6

Hi @lzaugg_parametric,

Offline updates still don’t have any explicit feedback other than the log output of Aktualizr. This is a short-coming we are aware of and plan to address in the future.

Best Regards,
Jeremias