Troubleshooting
Problem
The getcwd() system call may erroneously return an error EACCES or EPERM under certain circumstances when set to an IBM Rational ClearCase view and running on an Oracle Solaris 10 or Solaris 11 system. This error is typically only seen when running in a Solaris 10 Non-Global Zone or Branded Zone. The exact sequence of events that causes the error depend on the underlying filesystem, so the exact use case can vary. A common example of a program which uses the getcwd() system call is the pwd command.
Symptom
The symptom of this problem is an error on Solaris 10 and Solaris 11 systems when using ClearCase, such as:
pwd: cannot determine current directory!
If the failing command is part of a build which is executing, the user may not see the actual error, but the symptom may be that the build fails.
The error may be returned from any executable which invokes the getcwd() system call.
The error is more likely to occur for applications deployed in a Solaris 10 or Solaris 11 Non-Global Zone or Branded Zone.
Cause
For most directories, the getcwd() system call will be able to determine the correct pathname for a directory. Solaris 10 and Solaris 11 implement pathname caching. In certain circumstances which are unusual, when the cached pathname has become incorrect, the kernel encounters an error when trying to resolve the full and correct pathname of the current directory. In these specific circumstances, the getcwd() system call returns an error, and the command being executed (such as /bin/pwd) will fail.
Environment
ClearCase is installed on Solaris 10 or 11, on either SPARC or x86, typically in a Non-Global Zone or Branded Zone, and a getcwd() system call is run from a process which is set to a ClearCase view on a directory with an incorrect cached pathname.
Diagnosing The Problem
Truss output of the failing executable will typically show either EPERM or EACCES return from getcwd().
It is useful to make note of whether the directory for which getcwd() is failing is below a VOB mount point, or not. In situations where the error is reproducible, it can also be helpful to make note of the operations on that directory prior to the error.
Because this problem occurs when the pathname which is cached in the kernel's vnode data structure is incorrect, it may be possible to work around the failure by altering the sequence of actions taken on the directory. Avoiding operations such as moving or renaming the directory, if possible, may result in the kernel maintaining a correct pathname, thus, eliminating the problem.
Resolving The Problem
For Solaris 10, patches 147440-24 (SPARC) or 147441-24 (x86) eliminate this problem. These are also included in Solaris 10 Update 11 and greater.
Solaris 11 Update 1 includes the equivalent solution.
Note that starting with ClearCase 7.1.1.6 and 7.1.2.3, a pair of new libraries are shipped with ClearCase, 32-bit and 64-bit versions of libatriagetcwd_intersposer.so. These libraries contain code which interposes on the getcwd() system call with logic to work-around the problem. Use of these libraries requires setting the environment variables LD_PRELOAD_32 and LD_PRELOAD_64 with the path to the libraries. When the Solaris patch or update has been installed, this workaround is no longer required. Furthermore, these libraries are no longer included in the ClearCase release as of version 8.0.1.
The specific libraries which are no longer needed with the proper Solaris patches, and no longer shipped with ClearCase 8.0.1 are:
SPARC:
/usr/atria/shlib/libatriagetcwd_interposer.so
/usr/atria/shlib/sparcv9/libatriagetcwd_interposer.so
Solaris X86:
/usr/atria/shlib/libatriagetcwd_interposer.so
/usr/atria/shlib/amd64/libatriagetcwd_interposer.so
Was this topic helpful?
Document Information
Modified date:
06 November 2018
UID
swg21501830