Bug #19585
Updated by François ARMAND over 2 years ago
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 each
* cp inv.ocs.gz sig.sign.gz /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.