Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

Unable to lock file /.jazz5/.jazzlock null

Questions
Tags
Users
Badges
Shinobu Ishida
(137●1●9●15) Apr 10 '12, 1:55 a.m.
I encounterd this error when Accepting changes into workspace during the JBE build.

RTC Version :3.0.1.1
RTC Server :Windows2003 R2 SP2(Tomcat/Derby)
RTC Client :WindowsXP SP3
Build Server:Solaris10

The build log;
-----------------------------------------------------------------------
2012-04-09 20:43:50
2012-04-09 20:43:50 running on host: solaris10
2012-04-09 20:43:50 Should build occur?
2012-04-09 20:43:50 Yes: Always build a user initiated request.
2012-04-09 20:43:50 invoking pre-build participant "com.ibm.team.build.jazzscm"
2012-04-09 20:43:50 Accepting changes into workspace "blduser_batch_ws" ....
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess: Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock file /tmp/RTC/test5/.jazz5/.jazzlock null
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:43)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createSharingMetadata(CopyFileAreaManager.java:167)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:315)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:1)
at com.ibm.team.filesystem.client.internal.SharingManager.register(SharingManager.java:1002)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:188)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:845)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:651)
at java.lang.Thread.run(Thread.java:662)
-----------------------------------------------------------------------


My question is:
a) The build repo workspace has one local workspace. No one use this as the develop workspase. Then what locks the local workspace? (JBE daemon, lscm command daemon or something other?)

b) As a workaround, I deleted the file /.jazz5/.jazzlock manually and required the build again, then it works successfully.
Is deleting .jazzlock a problem? Does it cause another issue?


Thanks in advance!

0 votes

5 answers
22,349 views
0 votes

5 answers

Permanent link
Shashikant Padur
JAZZ DEVELOPER (4.3k●2●7) Apr 11 '12, 12:50 a.m.
Probably the scm daemon process is still alive and did not shutdown and is holding a lock to the sandbox. I am not too familiar with JBE as to when does it shutdown the daemon. You can run the following command "scm list daemon" and see if there is a daemon process running and the sandboxes tracked by that daemon process. If you would like to shutdown the daemon you can run the "scm daemon stop" command.


I encounterd this error when Accepting changes into workspace during the JBE build.

RTC Version :3.0.1.1
RTC Server :Windows2003 R2 SP2(Tomcat/Derby)
RTC Client :WindowsXP SP3
Build Server:Solaris10

The build log;
-----------------------------------------------------------------------
2012-04-09 20:43:50
2012-04-09 20:43:50 running on host: solaris10
2012-04-09 20:43:50 Should build occur?
2012-04-09 20:43:50 Yes: Always build a user initiated request.
2012-04-09 20:43:50 invoking pre-build participant "com.ibm.team.build.jazzscm"
2012-04-09 20:43:50 Accepting changes into workspace "blduser_batch_ws" ....
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess: Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock file /tmp/RTC/test5/.jazz5/.jazzlock null
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:43)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createSharingMetadata(CopyFileAreaManager.java:167)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:315)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:1)
at com.ibm.team.filesystem.client.internal.SharingManager.register(SharingManager.java:1002)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:188)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:845)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:651)
at java.lang.Thread.run(Thread.java:662)
-----------------------------------------------------------------------


My question is:
a) The build repo workspace has one local workspace. No one use this as the develop workspase. Then what locks the local workspace? (JBE daemon, lscm command daemon or something other?)

b) As a workaround, I deleted the file /.jazz5/.jazzlock manually and required the build again, then it works successfully.
Is deleting .jazzlock a problem? Does it cause another issue?


Thanks in advance!

1 vote

Permanent link
Jirong Hu
(1.5k●9●295●258) Apr 10 '12, 9:28 a.m.
I see this if I am using the command line "scm" at the same time. The error didn't go even if I close the command window, so I have to restart the machine. Let me know if you find a solution.

Thanks
Jirong

0 votes

Permanent link
Shinobu Ishida
(137●1●9●15) Apr 20 '12, 12:27 a.m.
Hi, Shashikant,

I run the "scm logout" command in my build script, but after the build I could find the scm daemon was still alive by the "scm list daemon" command.
"scm daemon stop" could resolve the error :D

Thanks for the help!


Probably the scm daemon process is still alive and did not shutdown and is holding a lock to the sandbox. I am not too familiar with JBE as to when does it shutdown the daemon. You can run the following command "scm list daemon" and see if there is a daemon process running and the sandboxes tracked by that daemon process. If you would like to shutdown the daemon you can run the "scm daemon stop" command.


I encounterd this error when Accepting changes into workspace during the JBE build.

RTC Version :3.0.1.1
RTC Server :Windows2003 R2 SP2(Tomcat/Derby)
RTC Client :WindowsXP SP3
Build Server:Solaris10

The build log;
-----------------------------------------------------------------------
2012-04-09 20:43:50
2012-04-09 20:43:50 running on host: solaris10
2012-04-09 20:43:50 Should build occur?
2012-04-09 20:43:50 Yes: Always build a user initiated request.
2012-04-09 20:43:50 invoking pre-build participant "com.ibm.team.build.jazzscm"
2012-04-09 20:43:50 Accepting changes into workspace "blduser_batch_ws" ....
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess: Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock file /tmp/RTC/test5/.jazz5/.jazzlock null
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:43)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createSharingMetadata(CopyFileAreaManager.java:167)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:315)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:1)
at com.ibm.team.filesystem.client.internal.SharingManager.register(SharingManager.java:1002)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:188)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:845)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:651)
at java.lang.Thread.run(Thread.java:662)
-----------------------------------------------------------------------


My question is:
a) The build repo workspace has one local workspace. No one use this as the develop workspase. Then what locks the local workspace? (JBE daemon, lscm command daemon or something other?)

b) As a workaround, I deleted the file /.jazz5/.jazzlock manually and required the build again, then it works successfully.
Is deleting .jazzlock a problem? Does it cause another issue?


Thanks in advance!

0 votes

Permanent link
Spencer Murata
FORUM MODERATOR / JAZZ DEVELOPER (2.3k●11●59●71) Apr 26 '12, 2:15 p.m.
I want to add in here that lscm.bat creates that daemon to prevent loading the scm jars every time. So you should use lscm.bat if you plan on executing several scm statements in a row, but you should be aware that the daemon will exist until you terminate the session. scm.exe will load everything, execute and go away. Lscm.bat can cause strange behavior in build tools if you don't take care of the daemon. For example if you use Hudson to execute a lscm.bat, the job will not complete until the daemon is terminated, so if you don't clean up the daemon, you will see the build just sitting in the running state forever. A similar action is happening here as something has executed and is waiting for the process tree to complete, but it never will unless you close the daemon as part of the build process.

~Spencer


Hi, Shashikant,

I run the "scm logout" command in my build script, but after the build I could find the scm daemon was still alive by the "scm list daemon" command.
"scm daemon stop" could resolve the error :D

Thanks for the help!


Probably the scm daemon process is still alive and did not shutdown and is holding a lock to the sandbox. I am not too familiar with JBE as to when does it shutdown the daemon. You can run the following command "scm list daemon" and see if there is a daemon process running and the sandboxes tracked by that daemon process. If you would like to shutdown the daemon you can run the "scm daemon stop" command.


I encounterd this error when Accepting changes into workspace during the JBE build.

RTC Version :3.0.1.1
RTC Server :Windows2003 R2 SP2(Tomcat/Derby)
RTC Client :WindowsXP SP3
Build Server:Solaris10

The build log;
-----------------------------------------------------------------------
2012-04-09 20:43:50
2012-04-09 20:43:50 running on host: solaris10
2012-04-09 20:43:50 Should build occur?
2012-04-09 20:43:50 Yes: Always build a user initiated request.
2012-04-09 20:43:50 invoking pre-build participant "com.ibm.team.build.jazzscm"
2012-04-09 20:43:50 Accepting changes into workspace "blduser_batch_ws" ....
com.ibm.team.filesystem.client.CopyFileAreaLockedByOtherProcess: Status INFO: com.ibm.team.filesystem.client code=0 Unable to lock file /tmp/RTC/test5/.jazz5/.jazzlock null
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.ensureExclusiveCFAAccess(SharingMetadata2.java:3074)
at com.ibm.team.filesystem.client.internal.core.SharingMetadata2.<init>(SharingMetadata2.java:1636)
at com.ibm.team.filesystem.client.internal.core.SharingMetadataFactory.getSharingMetadata(SharingMetadataFactory.java:43)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createSharingMetadata(CopyFileAreaManager.java:167)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:315)
at com.ibm.team.filesystem.client.internal.copyfileareas.CopyFileAreaManager.createCopyFileArea(CopyFileAreaManager.java:1)
at com.ibm.team.filesystem.client.internal.SharingManager.register(SharingManager.java:1002)
at com.ibm.team.build.internal.engine.JazzScmPreBuildParticipant.preBuild(JazzScmPreBuildParticipant.java:188)
at com.ibm.team.build.internal.engine.BuildLoop.invokePreBuildParticipants(BuildLoop.java:845)
at com.ibm.team.build.internal.engine.BuildLoop$2.run(BuildLoop.java:651)
at java.lang.Thread.run(Thread.java:662)
-----------------------------------------------------------------------


My question is:
a) The build repo workspace has one local workspace. No one use this as the develop workspase. Then what locks the local workspace? (JBE daemon, lscm command daemon or something other?)

b) As a workaround, I deleted the file /.jazz5/.jazzlock manually and required the build again, then it works successfully.
Is deleting .jazzlock a problem? Does it cause another issue?


Thanks in advance!

0 votes

Permanent link
Natarajan Thirumeni
(53●1●4●5) Feb 05 '14, 6:28 a.m.
I´ve had same issue where I cannot share my project after running both scm and Eclipse. I had to kill scm.exe from the taskmanager then I was able to deliver my changes. This on CLM 405 scm tools and CLM 405 server.

0 votes

Your answer

Register or log in 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.

Ask a question
Guidelines
FAQ
Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details

Question asked: Apr 10 '12, 1:55 a.m.

Question was seen: 22,349 times

Last updated: Feb 05 '14, 6:28 a.m.

Confirmation Cancel Confirm