-
Title
Is there a way to clear database lock without killing all user processes? -
Description
You receive an Error: 16 when trying to run a vastool flush. Is there a way to clear database lock without killing all user processes?
-
Resolution
To clear the database lock do the following:
1) mv /var/opt/quest/vas/vasd/vas_ident.vdb /var/opt/quest/vas/vasd/vas_ident.vdb.mv
2) mv /var/opt/quest/vas/vasd/vas_misc.vdb /var/opt/quest/vas/vasd/vas_misc.vdb.mv
3) cp -p /var/opt/quest/vas/vasd/vas_ident.vdb.mv /var/opt/quest/vas/vasd/vas_ident.vdb
4) cp -p /var/opt/quest/vas/vasd/vas_misc.vdb.mv /var/opt/quest/vas/vasd/vas_misc.vdb
The file lock stays on the moved file, and new processes are able to read the same info from the copied file. -
Additional Information
When an application makes getgrent() or getpwent() calls, it will create a temporary lock on the cache files vasd owns. This normally does not cause any problems, as the locks are released quickly when the application calls endgrent() or endpwent(). However, some applications do not always call the endXXent() functions, which creates an undesired effect of keeping the lock for the life of the application.
In QAS 3.1+, the setting given below will force the NSS library to use memory based caches, which avoid creating a lock on the cache at the expense of memory.
Preventing the issue:
VAS 3.1+ has a setting called getent-use-memory-cache true in the vas.conf under the nss_vas section that will stop this from happening In setting this option to true, each process that calls the getXXent() functions will run slower and consume more memory. This is a global setting that will affect all processes. (It is still efficient, and the memory usage should not be noticable in normal usages).
To configure your vas.conf with this option run
# /opt/quest/bin/vastool configure vas nss_vas getent-use-memory-cache true