It's all about the answers!

Ask a question
QuestionsTagsUsersBadges
Guidelines | FAQ
Follow this question
Question details

×42,882
×6,035
×1,201
×889
×158
×113

question asked: Nov 19 '13, 5:55 p.m.
question was seen: 9,039 times
last updated: Dec 16 '13, 5:49 p.m.

Related questions

What is the basis of "Failed to acquire locks on requested sandboxes"?

0
1
Andy Jewell (242●3●63●74) | asked Nov 19 '13, 5:55 p.m.
retagged Dec 16 '13, 5:49 p.m. by David Lafreniere (4.8k●7)
I get this error periodically using RTC 4.0.3 command line client, typically doing a status or an accept. 

	Failed to acquire locks on requested sandboxes

My standard yet ineffective approach to this is:

  1. Logout of any local sessions (lscm logout)
  2. Kill any running workspace daemons (scm daemon stop)
  3. Recycle my terminal session (start a new shell)
This occurs even when I'm the only user of the workspace and I've come into the workspace from a fresh reboot of my client PC.  I don't do anything with file locks so I'm really not even sure what this error is telling me.

So that's my question:)  What IS this telling me?  What do I do to resolve it?  I read one other note on the forum where Geoffery suggests increasing the timeout.  However, my timeout is already at 2 minutes which I think is already excessive but is apparently how our administrators set it up.

Any suggestions on this error would be greatly appreciated!


- Andy
Comments
1
Shashikant Padur commented Nov 20 '13, 6:01 a.m.
JAZZ DEVELOPER

As I understand increasing the timeout does not help because it is fixed to 60000 ms.

I believe this could happen when the tool tries to lock the daemon's registry location and determines which daemon to use.
Can you run 'scm ls daemon' and see if it is able to list the daemons?

Andy Jewell commented Nov 20 '13, 10:50 a.m.

Normally, I do stop the workspace daemon, having done 'lscm list daemons' followed by 'scm daemon stop'.  Next time I get this issue I will try 'scm ls daemon' and see if it differs.

Andy Jewell commented Nov 21 '13, 7:30 p.m.

 I'm not sure if it was the solution or not, but after listing the daemons:


c:\Users\O386600\mbe-workspaces\hp_mbe_o_2013_12_01>scm ls daemons
Port  Description
56752 Jazz CLI (3.1.300.v20130426_0115)
53949 Jazz CLI (3.1.300.v20130426_0115)
56765 Jazz CLI (3.1.300.v20130426_0115)
  C:\Users\O386600\build-process-test
53977 Jazz CLI (3.1.300.v20130426_0115)
53484 Jazz CLI (3.1.300.v20130426_0115)
  C:\Users\O386600\mbe-workspaces\build_process_o386600

I found quite a few CLI daemons.  Generally, I think I was just stopping the workspace daemon (Eclipse?).  This time I used scm stop daemon -p <port> for each Jazz CLI daemon and it seemed to cure the sandbox lock issue.  I'm not 100% because I thought I'd done this in the past, but it worked in this case.  Thanks, Shashikant!

Be the first one to answer this question!

Register or to post your answer.


Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.