Project

General

Profile

Actions

Bug #19585

closed

Sometime inventory processing is not done when inventory is receveived

Added by Nicolas CHARLES over 3 years ago. Updated over 2 years ago.

Status:
Released
Priority:
N/A
Category:
Web - Nodes & inventories
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
0
Name check:
To do
Fix check:
Checked
Regression:

Description

it took a full 6 minutes for the webapp to identify that inventory was sitting in /var/rudder/inventories/accepted-nodes-updates/

Edit: so the problem is due to a lock not correctly removed in every case when there is several file processed: it seems to happen more frequently if both signature and inventory file are gzipped, and with sign first.

When that happens, the first file (gz) takes the lock, then the second (gz) can not be processed (because lock hold and gzip processing), then we get an other for the unlocked file (sign) which wait for inventory (because still gz), and the gz file is never processed and the lock is not removed.

Then, I'm not sure how, the next (or the next next) inventory processing round remove the lock and the next can be processed Ok (because there's lots of file unzipped on the fs, so things can go on).

Test correction

  • Take a pair of inventory/signature (for ex in received)
  • gzip ocs
  • cp inv.ocs.gz sig.sign /var/rudder/inventories/incoming
    Do it several times (4 of 5): it should always lead to a webapp log "new inventory .." "inventory parsed in XXX" and NOT the "inventory already processing" one.

Related issues 2 (0 open2 closed)

Related to Rudder - Architecture #19920: root inventory is missing and need to be resent after installReleasedNicolas CHARLESActions
Has duplicate Rudder - Bug #20994: Some inventories are stuck in the incoming folderResolvedActions
Actions

Also available in: Atom PDF