add polling support #1672
add polling support #1672
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #1672 +/- ##
==========================================
- Coverage 84.48% 84.47% -0.01%
==========================================
Files 76 77 +1
Lines 22286 22730 +444
==========================================
+ Hits 18828 19201 +373
- Misses 3458 3529 +71
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
src/poll.c
Outdated
| const gchar *cmd = r_context()->config->poll_reboot_cmd; | ||
| g_assert(cmd); |
There was a problem hiding this comment.
I am currently experimenting with the feature. According to the documentation setting a reboot-cmd is optional and the default (reboot) should be used if none is set, but I've hit this assertion with no (reboot-cmd) set in the config.
Mar 26 13:18:50 lxatac-00011 rauc[541]: polling: installation of `http://192.168.94.2:40080/update.raucb` succeeded
Mar 26 13:18:50 lxatac-00011 rauc[541]: scheduled next poll in: 15s
Mar 26 13:19:05 lxatac-00011 rauc[541]: **
Mar 26 13:19:05 lxatac-00011 rauc[541]: rauc:ERROR:/usr/src/debug/rauc/1.13+git/src/poll.c:322:poll_reboot: assertion failed: (cmd)
Mar 26 13:19:05 lxatac-00011 rauc[541]: Bail out! rauc:ERROR:/usr/src/debug/rauc/1.13+git/src/poll.c:322:poll_reboot: assertion failed: (cmd)
Mar 26 13:19:07 lxatac-00011 systemd[1]: rauc.service: Main process exited, code=dumped, status=6/ABRT
Mar 26 13:19:07 lxatac-00011 systemd[1]: rauc.service: Failed with result 'core-dump
There was a problem hiding this comment.
Correct, the default is missing.
|
From using the feature it does not look like there is a lot of debug output (by default default) about which candidate-/install-/reboot-criteria are met by a polled bundle and which are not. Something along the lines of:
|
Update the source revision to the current master branch tip and apply the polling support pull request[1] on top of it. The PR is applied as patches instead of an updated SRCREV because the PR branch is very likely to be force-pushed again. [1]: rauc/rauc#1672 Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Update the source revision to the v14.1 release and apply the polling support pull request[1] on top of it. The PR is applied as patches instead of an updated SRCREV because the PR branch is very likely to be force-pushed again. [1]: rauc/rauc#1672 Signed-off-by: Leonard Göhrs <l.goehrs@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
This will allow us to determine if a reboot should be performed after an automatic installation. Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
The helper also optionally checks the strings against an allow-list. Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
This is useful for testing handling of aspects like 204 no content. Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
test/conftest.py
Outdated
| @@ -147,6 +147,7 @@ def _have_faketime(): | |||
|
|
|||
|
|
|||
| no_service = pytest.mark.skipif(string_in_config_h("ENABLE_SERVICE 1"), reason="Have service") | |||
| needs_service = pytest.mark.skipif(not string_in_config_h("ENABLE_SERVICE 1"), reason="Have service") | |||
There was a problem hiding this comment.
| needs_service = pytest.mark.skipif(not string_in_config_h("ENABLE_SERVICE 1"), reason="Have service") | |
| needs_service = pytest.mark.skipif(not string_in_config_h("ENABLE_SERVICE 1"), reason="Need service") |
test/test_polling.py
Outdated
|
|
||
|
|
||
| def test_poll_only(create_system_files, system, http_server): | ||
| """Test if the info command sends custom headers correctly.""" |
There was a problem hiding this comment.
I think the docstrings in this file are not up to date.
docs/advanced.rst
Outdated
| [poll] | ||
| source=https://example.com/stable/my_product.raucb | ||
| interval-sec=300 | ||
| max-interval-sec=3600 | ||
|
|
||
| In this example: | ||
|
|
||
| * RAUC polls the source every 5 minutes as long as no error occurs. | ||
| * Every time a poll attempt fails, the interval is increased by 5 minutes, until | ||
| it reaches 1 hour. | ||
| * If an attempt is successful again, the interval is reduced to 5 minutes. |
There was a problem hiding this comment.
The documentation should contain best practices. Polling every five minutes sounds excessive to me.
How about e.g.
interval-sec=14400
max-interval-sec=86400
e.g. four hours and one day respectively. Four hours still sounds a bit too frequent for my taste, but at least hacker news will not make fun of it.
| ``candidate-criteria`` (optional, default is ``higher-semver``) | ||
| Specifies the conditions under which a new bundle is considered a **candidate** | ||
| for updating. | ||
| These conditions do **not** automatically trigger the installation of the | ||
| update. | ||
|
|
||
| Supported values are: | ||
|
|
||
| * ``higher-semver``: The new bundle's version (interpreted as a Semantic | ||
| Version) is higher than the current system version. | ||
| * ``different-version``: The new bundle's version string differs from the | ||
| current system version (regardless of ordering). |
There was a problem hiding this comment.
I use the DBus poller status property to get the compatible, version, manifest_hash and effective_url of the remote bundle. I want these (and the other fields I do not use) to always be up to date with the results of the previous poll.
I did not yet fully grasp if that is the case, or if this information is only available if candidate-criteria matches.
Should I set candidate-criteria= (empty) in order to also see the remote bundle information via the status property if the semver of the current image and the remote bundle happen to match?
(The code in question, if you are interested linux-automation/tacd@0ab21a3 linux-automation/tacd@911e489)
There was a problem hiding this comment.
Hmm. We should rethink the behavior here. It could still be useful to expose the manifest even if the poller decides this version is not a candidate. The decision should be exposed in this case as well.
This aspect probably also needs some specific documentation.
|
@ejoerns @hnez Which clock base should we use for the |
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
|
I've renamed the |
This implements large parts of rauc#1114 (Simple Update Server Support). The polling functionality in RAUC allows a device to periodically check for updates from a specified source. It fetches bundle manifests, checks for available updates, and initiates installations if necessary. This functionality is intended to automate the update process and ensure that the system remains up-to-date with minimal manual intervention. Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
Signed-off-by: Jan Luebbe <jlu@pengutronix.de>
| NULL | ||
| }; | ||
|
|
||
| static gboolean parse_polling_config(RaucConfig *config, GKeyFile *key_file, GError **error) |
Check warning
Code scanning / CodeQL
Poorly documented large function Warning
|
The last force-push now also renames the new source files. |
This is based on the concept described in #1114.
Documentation:
TODO: