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 accept
ing 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
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