Tip: Using the SCM Command Line with NFS
Summary
Some NFS file systems do not allow locks to be acquired on the shared filesystem which prevents the source control command line interfaces (scm and lscm) from working.
This article describes how to diagnose locking issues and provides work arounds for dealing with NFS.
More Information
Symptoms
When NFS prevents scm from locking the filesystem, most subcommands will print the following error message:
Could not initialize data area: No scratch OSGi roots available. Delete one or more of the numbered directories in /path/to/configuration/area
and immediately exit with the return code of 27. The default configuration area is named .jazz-scm and is placed at the root of your home directory. You can place it elsewhere by specifying the --config argument or setting the SCM_CONFIG_DIRECTORY environment variable.
The scm load subcommand fails with a different message. If you try to load into a filesystem that prevents locks from being acquired, it will print:
Problem running 'load': Another RCP application is running in this local workspace. File locked at file: /path/to/load/root
Diagnosis
Both of these symptoms may be caused by:
- another process holding locks in the given directories, or
- a filesystem that prevents locks from being acquired.
Verifying that the configuration area isn’t locked
The configuration area contains a directory named scratch which holds up to ten numbered directories (ie, 0, 1, 2, etc). If there are ten scm processes running, they will exhaust those numbered directories. You can check if the directories have been exhausted by running lsof on the OSGi lock in each of the numbered directories. The lock is found at .metadata/lock.
If the file is open (and presumably locked), lsof prints:
~/.jazz-scm/scratch$ lsof 0/.metadata/.lock COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME scm 2638 echughes 89uw REG 8,1 0 8260833 0/.metadata/.lock
If the file is not open, lsof will quietly exit:
~/.jazz-scm/scratch$ lsof 1/.metadata/.lock ~/.jazz-scm/scratch$
You can use the -V argument to get a more verbose confirmation that the file is not in use.
Verifying that the sandbox root isn’t locked
You can use lsof to verify that the sandbox root is not locked during an scm load. The file in question is found at .metadata/.lock in the sandbox root.
Resolution
If the aforementioned files are not locked and the directories are on NFS filesystems, then there may be an NFS issue. You have a number of options:
- place the configuration area or load root on a non-NFS filesystem,
- configure NFS to allow locking, or
- stop using NFS.
You can move the configuration area by specifying scm --config /path/to/non-NFS/filesystem on every invocation, or (in 3.0) specifying the SCM_CONFIG_DIRECTORY environment variable.
Yes