# Inventory update after accepting a device

**URL:** <https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669>\
**Category:** General Discussions\
**Created:** [March 12, 2023, 2:54pm UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669 "2023-03-12T14:54:23Z")\
**Posts on this page:** 9\
**Page:** 1

<div class="post-metadata">

**Author:** ![netsolom](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/netsolom/32/1697_2.png) [@netsolom](https://hub.mender.io/u/netsolom)\
**Post date:** [March 12, 2023, 2:54pm UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/1 "2023-03-12T14:54:24Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![netsolom](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/netsolom/32/1697_2.png) [@netsolom](https://hub.mender.io/u/netsolom)\
**Post date:** [April 3, 2023, 12:27pm UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/2 "2023-04-03T12:27:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mister\_kanister](https://avatars.discourse-cdn.com/v4/letter/m/8edcca/32.png) [@mister\_kanister](https://hub.mender.io/u/mister_kanister)\
**Post date:** [April 3, 2023, 2:35pm UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/3 "2023-04-03T14:35:03Z")

</div>

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.

```auto
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.

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

```

With contents like

```auto
echo "device_type=$DEVICE_TYPE"

```

Take a look at already present scripts

---

<div class="post-metadata">

**Author:** ![netsolom](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/netsolom/32/1697_2.png) [@netsolom](https://hub.mender.io/u/netsolom)\
**Post date:** [April 3, 2023, 3:46pm UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/4 "2023-04-03T15:46:00Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![netsolom](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/netsolom/32/1697_2.png) [@netsolom](https://hub.mender.io/u/netsolom)\
**Post date:** [April 4, 2023, 6:01am UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/5 "2023-04-04T06:01:28Z")

</div>

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

```auto
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 😬

```auto
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.

---

<div class="post-metadata">

**Author:** ![netsolom](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/netsolom/32/1697_2.png) [@netsolom](https://hub.mender.io/u/netsolom)\
**Post date:** [April 12, 2023, 9:58am UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/6 "2023-04-12T09:58:25Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [April 13, 2023, 11:39am UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/7 "2023-04-13T11:39:57Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![netsolom](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/netsolom/32/1697_2.png) [@netsolom](https://hub.mender.io/u/netsolom)\
**Post date:** [April 13, 2023, 12:55pm UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/8 "2023-04-13T12:55:51Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![TheYoctoJester](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/theyoctojester/32/1444_2.png) [@TheYoctoJester](https://hub.mender.io/u/TheYoctoJester)\
**Post date:** [April 14, 2023, 9:42am UTC](https://hub.mender.io/t/inventory-update-after-accepting-a-device/5669/9 "2023-04-14T09:42:51Z")

</div>

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](https://hub.mender.io/t/mender-to-rewrite-client-using-c-and-retain-go-for-its-backend/5332) not on the roadmap, at least not for the Go-based client.

Greets,  
Josef