Rocket U2 | UniVerse & UniData

 View Only

 How to kill a session which is 'lock Waiter' /uv windows 11.3

manu fernandes's profile image
PARTNER manu fernandes posted 09-14-2022 03:56
hi folks,

I have the session 99 into a READU statement and lock is owned by  port 10 ... then 99 appears into Active waiters as a Waiter and Owner is 10. 

Now, I want to MASTER OFF 99 ...  nothing occurs ! no message, no error, no result. 

Is anyone known a method to kill a 'lock Waiter' session ? 

with kind regards 
Andrew Milne's profile image
Andrew Milne

Hi Manu,

several things to try, if the user of session 99 can get to TCL in another session they should be able to LO - 99 and logout that rogue session.

from within  U2 Extensible ADMIN > LOCKS try Clear Locks for that PID (99) session, from within the File Lock Waiters TAB, which you've probably already tried

Have you looked for any Dead Locks

And finally and probably completely unapproved and am sure one of the Rocketeers (John Jenkins ) will offer the real approved method, if you go into Windows Task Manager and look for the TL_SERVER.exe with the PID = the session umber (99) and End Task, that will free the windows activity. and you should be able to close that session in U2 Extensible ADMIN > USERS

I hope this helps, but again all at your own risk !!!!



Will Johnson's profile image
Will Johnson
It is possible that you need admin rights.  Have you tried logging in as Administrator before you try to do this
manu fernandes's profile image
PARTNER manu fernandes
Hi Andrew, Hi Will,
Thanks for your response.
Yes, I 'm administrator with elevated right shell. 

So, I must do it from Administrator perspective, I can not ask user of session 99 to open a new one and perform action to LO 99, it's SBXA/XUI activities.
Logged as Administrator, from U2Ext, It does not work to 'kill'  99 if it is 'lock waiter' - nothing appends.
I'm not in a dead lock situation,  99 is simple 'lock waiter' - 99 own no other lock . (If it's a deadlock situation, Deadlock deamon make a good job and kill the main lock owner.)

I found a solution with windows tool TASKKILL /PID xxx /F  ; then UVcleanupd clear the internal situation.  not the most elegant but it works.  
I'll try powershell Stop-Process.


Neil Morris's profile image
Hi Manu,
The behavior you reported regarding the MASTER OFF command was recently discovered. Apparently it is a long standing behavior where the MASTER OFF command on a user that was in a read waiter situation would not log off the process. Your method of killing the process and letting uvcleanupd handle the situation is the best method at this point. A ticket (UNV-32918) has been opened to have this behavior investigated.