Library Manager - open terminal option on right clicking any cell or views

You could do this with the library manager customisation SKILL functions covered in the Library Manager Functions chapter of the Cadence Application Infrastructure SKILL Reference.

I wonder why you would need to do this though - it's the kind of thing that I might do as an application engineer to check when something is broken, but I'm a bit surprised that you'd need to do this very often?

Andrew

My admin has enabled failsafe for all applications including virtuoso which gets auto-killed after certain period of time. This leaves lock files.
Also, can we add option like fix lock file under right click? I have seen coth state option in one of old project.

Removing lock files this way is generally a bad (and risky) thing to do. It suggests that your system is not set up correctly and your admin should address this.

The locking infrastructure relies on a couple of lightweight processes, clsbd and oaFSLockD (the latter is a similar process for OA data). These are both what are referred to as "boolean daemons". All they are there for is for a process (which might be remote) to be able to enquire whether a given process id is still alive on the machine they are running on, and return a yes/no (true/false) answer - hence the term "boolean". 

When Virtuoso tries to lock a file and there's an existing lock file, then it will look in the lock file and determine the host and process id which had the lock. It then contacts the boolean daemon (either clsbd or oaFSLockD depending on the kind of data) and asks whether that process id is alive or not. If it's not alive, then the lock can be reclaimed and the new process can lock it instead. If either the process is still running or there is no answer (in which case it can't be determined safely) then the lock request is denied. 

There are two approaches to running clsbd and oaFSLockD - one is to let them be launched the first time that Virtuoso starts (they normally persist beyond the execution of Virtuoso), but this runs the risk of killer mechanisms such as you describe taking them out. You can set up the "daemon starter" to separate them from the parent process, but again your killer mechanism should leave them alone. Or they could be started at boot time as a system service and kept alive (which needs admin work). The benefit of the latter is that if the machine is rebooted you don't have to wait until somebody runs Virtuoso on the machine for the stranded lock recovery mechanism to work.

There is a UNIX command, clsAdminTool which can be used to look for and remove lock files - although this does not check that the lock being removed is not genuinely locked elsewhere - this is intended to be the backup mechanism if all else has failed (e.g. the machine with the lock is no longer accessible). If the stranded lock recovery mechanism is working and everything is normal, it should be very rare to need to remove lock files.

I would be very wary of having a menu in the library manager to remove lock files because users would not know if the lock was genuine, and removing a lock when it is genuinely still locked can lead to loss of data (since two processes think they they own the data, you get whoever wrote last).

Andrew

Removing lock files this way is generally a bad (and risky) thing to do. It suggests that your system is not set up correctly and your admin should address this.

The locking infrastructure relies on a couple of lightweight processes, clsbd and oaFSLockD (the latter is a similar process for OA data). These are both what are referred to as "boolean daemons". All they are there for is for a process (which might be remote) to be able to enquire whether a given process id is still alive on the machine they are running on, and return a yes/no (true/false) answer - hence the term "boolean". 

When Virtuoso tries to lock a file and there's an existing lock file, then it will look in the lock file and determine the host and process id which had the lock. It then contacts the boolean daemon (either clsbd or oaFSLockD depending on the kind of data) and asks whether that process id is alive or not. If it's not alive, then the lock can be reclaimed and the new process can lock it instead. If either the process is still running or there is no answer (in which case it can't be determined safely) then the lock request is denied. 

There are two approaches to running clsbd and oaFSLockD - one is to let them be launched the first time that Virtuoso starts (they normally persist beyond the execution of Virtuoso), but this runs the risk of killer mechanisms such as you describe taking them out. You can set up the "daemon starter" to separate them from the parent process, but again your killer mechanism should leave them alone. Or they could be started at boot time as a system service and kept alive (which needs admin work). The benefit of the latter is that if the machine is rebooted you don't have to wait until somebody runs Virtuoso on the machine for the stranded lock recovery mechanism to work.

There is a UNIX command, clsAdminTool which can be used to look for and remove lock files - although this does not check that the lock being removed is not genuinely locked elsewhere - this is intended to be the backup mechanism if all else has failed (e.g. the machine with the lock is no longer accessible). If the stranded lock recovery mechanism is working and everything is normal, it should be very rare to need to remove lock files.

I would be very wary of having a menu in the library manager to remove lock files because users would not know if the lock was genuine, and removing a lock when it is genuinely still locked can lead to loss of data (since two processes think they they own the data, you get whoever wrote last).

Andrew

Thanks Andrew for detailed explaination. I will check with my Admin to fix the issue.