Inventory update after accepting a device

Hi,

When will a client send his first inventory update after installation?
I thought that after successful authorization it should, however looking at the client logs I see it checks for an update but does not send an inventory.
Will he send it only after InventoryPollIntervalSeconds?

According to documentation, the client send an inventory update:

the client may occasionally post its inventory more often if there has been recent activity on the device

Thanks,
Neta

Hi,

Any information on this is welcomed.
I would like to use the device_type value immediately after accepting a device.
Is it possible?

Thanks

Usually after the device was accepted you will see something in the logs of mender-client, that the client is updating the inventory. While the mender-client is running you can add inventory on the fly. Maybe consider using --demo-polling so the time intervals are short.

mender setup \ 
--device-type $DEVICE_TYPE \
--server-url https://eu.hosted.mender.io \
--tenant-token $TENANT_TOKEN \
--demo-polling \
--server-cert /etc/mender/server.crt \
--data /var/lib/mender

You could add a custom script that will be automatically evaluated by the client and update the info.

/usr/share/mender/inventory/mender-inventory-<my_custom_script>

With contents like

echo "device_type=$DEVICE_TYPE"

Take a look at already present scripts

Thanks for the reply.

Indeed when I used --demo-polling I saw almost immediately inventory update, maybe because InventoryPollIntervalSeconds is set to 5.
However now when testing mender integration with our system I used the default 28800 (8 hours). After device is accepted, I see that it is mainly busy with checking for new updates (we set this value to 60 seconds), but there is no attempt for inventory update. Only after 8 hours.
Is there another configuration parameter that I need to set in order for it to happen immediately after a successful authorization?

Below is mender client logs from the time of the accept (that happened on Apr 03 09:37:13):

Apr 03 09:36:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:12Z" level=info msg="Device unauthorized; attempting reauthorization"
Apr 03 09:36:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=error msg="Failed to authorize with \"https://gc-mender\": (request_id: ): authentication request
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=error msg="Failed to authorize with \"https://gc-mender\": (request_id: ): authentication request
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=warning msg="Reauthorization failed with error: transient error: authorization request failed"
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=warning msg="Reauthorization failed with error: transient error: authorization request failed"
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=error msg="Error receiving scheduled update data: update check request failed: transient error: a
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=error msg="Update check failed: transient error: update check request failed: transient error: au
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=info msg="State transition: update-check [Sync] -> error [Error]"
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=error msg="Error receiving scheduled update data: update check request failed: transient error: a
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=info msg="Handling error state, current error: transient error: update check request failed: tran
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=info msg="State transition: error [Error] -> idle [Idle]"
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=info msg="State transition: idle [Idle] -> check-wait [Idle]"
Apr 03 09:36:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:36:13Z" level=error msg="Update check failed: transient error: update check request failed: transient error: au
Apr 03 09:37:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:12Z" level=info msg="State transition: check-wait [Idle] -> update-check [Sync]"
Apr 03 09:37:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:37:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:12Z" level=info msg="Device unauthorized; attempting reauthorization"
Apr 03 09:37:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:37:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:13Z" level=info msg="successfully received new authorization data from server https://gc-mender"
Apr 03 09:37:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:13Z" level=info msg="Local proxy started"
Apr 03 09:37:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:13Z" level=info msg="Reauthorization successful"
Apr 03 09:37:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:13Z" level=info msg="request POST to https://gc-mender/api/devices/v2/deployments/device/deployments/next re
Apr 03 09:37:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:37:13Z" level=info msg="State transition: update-check [Sync] -> check-wait [Idle]"
Apr 03 09:38:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:38:12Z" level=info msg="State transition: check-wait [Idle] -> update-check [Sync]"
Apr 03 09:38:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:38:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:38:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:38:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:38:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:38:12Z" level=info msg="request POST to https://gc-mender/api/devices/v2/deployments/device/deployments/next re
Apr 03 09:38:13 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:38:13Z" level=info msg="State transition: update-check [Sync] -> check-wait [Idle]"
Apr 03 09:39:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:39:12Z" level=info msg="State transition: check-wait [Idle] -> update-check [Sync]"
Apr 03 09:39:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:39:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:39:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:39:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in
Apr 03 09:39:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:39:12Z" level=info msg="request POST to https://gc-mender/api/devices/v2/deployments/device/deployments/next re
Apr 03 09:39:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:39:12Z" level=info msg="State transition: update-check [Sync] -> check-wait [Idle]"
Apr 03 09:40:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:40:12Z" level=info msg="State transition: check-wait [Idle] -> update-check [Sync]"
Apr 03 09:40:12 gc-aggregator-172-16-100-50 mender[19884]: time="2023-04-03T09:40:12Z" level=warning msg="Returning artifact name from /etc/mender/artifact_info file. This is a fallback, in

First attempt to send inventory is only at Apr 03 13:07:11 after a failed update :grimacing:

Apr 03 13:07:11 gc-aggregator-172-16-100-50 mender[1266]: time="2023-04-03T13:07:11Z" level=info msg="State transition: update-error [ArtifactFailure] -> cleanup [Error]"
Apr 03 13:07:11 gc-aggregator-172-16-100-50 mender[1266]: time="2023-04-03T13:07:11Z" level=info msg="State transition: cleanup [Error] -> update-status-report [none]"
Apr 03 13:07:11 gc-aggregator-172-16-100-50 mender[1266]: time="2023-04-03T13:07:11Z" level=info msg="State transition: update-status-report [none] -> idle [Idle]"
Apr 03 13:07:11 gc-aggregator-172-16-100-50 mender[1266]: time="2023-04-03T13:07:11Z" level=info msg="State transition: idle [Idle] -> check-wait [Idle]"
Apr 03 13:07:11 gc-aggregator-172-16-100-50 mender[1266]: time="2023-04-03T13:07:11Z" level=info msg="State transition: check-wait [Idle] -> inventory-update [Sync]"

I can add the full log file, but only image formats are allowed to be uploaded.

@mister_kanister Any thoughts why the device does not try to update inventory immediately after being accepted by the server?

Hi @netsolom,

As the device has no immediate way of being accepted until the next polling cycle, it is not able to update “immediately”. This behaviour is therefore intended.

Greetz,
Josef

Thanks @TheYoctoJester for the reply.
Can you elaborate? Why after successfully received new authorization data from server https://gc-mender the client cannot trigger an inventory update? Why in this special case of new authorization the state cannot move from update-check to inventory-update?
I understand the behavior is intended, but I wonder if this is a technical limitation.

Regards,
Neta

Hi @netsolom,

sorry, misunderstood the question, apologies.
Concerning the sync of of a first inventory update to receiving the acceptance, it is technically possible. However due to the currently ongoing rewrite not on the roadmap, at least not for the Go-based client.

Greets,
Josef