Tip: Using the SCM Command Line with NFS

Evan Hughes
Last Updated: November 9, 2010
Build Basis: All versions of RTC

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:

1. another process holding locks in the given directories, or
2. a filesystem that prevents locks from being acquired.

This tech tip covers the second scenario, so you should ensure that another process isn’t holding a lock on the configuration area or (in the case of load) the sandbox root. You can do so in the following manner.

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:

1. place the configuration area or load root on a non-NFS filesystem,
2. configure NFS to allow locking, or
3. 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.

Related Information

• Bug 111284: Cannot scm load workspace — Get “Another RCP Process” message