UCMDB Tip: Details of the UD Node Locks
In the past we encountered a number of issues dealing with the locks, especially for client devices, such as laptops/desktops that can change their IP addresses too frequently, all the known issues were fixed in recent content pack 12 and 13 updates, however if you come across any new problems, it might be useful to know some details about the UD Node locks:
- Locks are acquired at the beginning of the workflow’s operation for 24 hours. For example, the Inventory Discovery by Scanner job has the “Lock Scanner Node” step.
- Each subsequent step of the workflow that requires a lock will also ensure that the lock is acquired
- If the lock cannot be obtained (the node is already locked by another job), the workflow step fails and will be retried later
- You can see the steps of the workflow and the corresponding Jython scripts in the XML for the workflow (e.g. for Inventory Discovery by Scanner job you can check under Adapter Management > InventoryDiscovery > Adapters > InventoryDiscovery byScanner --> Workflow steps)
- The lock is stored in the agent option SCANNER_EXCLUSIVE_LOCK. It contains a number of fields separated by the \\\___\\\ separator string. The fields are as follows:
- Probe name
- Job Type
- Job Name
- The time the lock was acquired
- The expiration time of the lock
Note*: that the times are in UNIX time. You can use online resources to convert UNIX time to a readable time text string, for example: http://www.onlineconversion.com/unix_time.htm. UNIX time stamp is in seconds, while the lock time is in milliseconds, so when doing the conversion to text just drop the last 3 digits.
- When the lock is released (for Inventory Discovery – “Unlock Scanner Node” step in UnlockScannerNode.py), the SCANNER_EXCLUSIVE_LOCK agent option gets deleted
- If the lock is past its expiration date, it can be reacquired by another job
- You can see more of the logic dealing with locks in the LockUtils.py Jython script
- Once the lock value is acquired, the job stores the status of it on the probe in the database and will not check the remote value while it knows that it owns the lock
If you find that this or any post resolves your issue, please be sure to mark it as an accepted solution.”
Click the KUDOS star on the left to say 'Thanks'