JDK-6189256 : Inability to launch Java from inside ClearCase
  • Type: Bug
  • Component: tools
  • Sub-Component: launcher
  • Affected Version: 1.4.2,1.4.2_05
  • Priority: P4
  • Status: Closed
  • Resolution: Not an Issue
  • OS: linux,linux_redhat_3.0
  • CPU: x86
  • Submitted: 2004-11-02
  • Updated: 2010-08-06
  • Resolved: 2006-04-25
Related Reports
Duplicate :  
JDK-6199712 - Java won't run if installed in clearcase filesystem: could not find libjava.so
Relates :  
JDK-4673940 - Java networking applications should be startable from inetd/xinetd
Description
When attempting to execute JAVA (version 1.4.2_05) on a linux machine, from a no
n-standard pathname, some of the runtime shared libraries cannot be found.  From a trace of the system commands, JAVA attempts to find the libjava.so by using th
e ?/proc/self/exe? to find the pathname of the library.  This method does not wo
rk in conjunction with IBM/Rational ClearCase.

Customers who are developing software need to be able to recreate previous versi
ons of software, so they store copies of compilers, source code and versions of 
JAVA in their source control application (ClearCase). They then execute the stor
ed tools from the alternate pathname that is a clearcase vob.  Java is attemptin
g to figure out the pathname where Java is running from to build a pathname for 
related libraries.  Unfortunately the method Java is using on Linux (using /proc
/self/exe) to find a software library will not always work.  

ClearCase gives you the ability to use a pathname along with a version specifier
 to specify a particular version of a file to open.  ClearCase translates this p
athname and version specifier into another pathname in the UFS or NFS namespace 
which is filled in with the correct version contents.  So for example an open of
 /vobs/jay_unix_java/j2re1.4.2_06/bin/java with version 3 specified, might actua
lly open /home/jay/jay_java.vbs/c/cdft/9/22/1cf5f8ff188811d985e1000c29844b01 whi
ch is a UFS file that contains the correct content for version 3 of j2re1.4.2_06
/bin/java (through the magic of ClearCase).

JAVA needs to be more flexible and not base it path search on the path of where 
it is executed.  This issue was found when JAVA was exported into Rational?s Cle
arCase on a linux machine.    
 
The linux strace near the failure looks like this:

  getpid()                                = 4167
rt_sigaction(SIGRTMIN, {0x400399c0, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_1, {0x40038c90, [], 0x4000000}, NULL, 8) = 0
rt_sigaction(SIGRT_2, {0x40039a10, [], 0x4000000}, NULL, 8) = 0
rt_sigprocmask(SIG_BLOCK, [RTMIN], NULL, 8) = 0
_sysctl({{CTL_KERN, KERN_VERSION}, 2, 0xbffff50c, 31, (nil), 0}) = 0
brk(0)                                  = 0x8058354
brk(0x8058384)                          = 0x8058384
brk(0x8059000)                          = 0x8059000
readlink("/proc/self/exe", "/tmp_mnt/DYN9-34-93-188/usr/vobs/jay_java.vbs/c/cdft
/9/22/1cf5f8ff188811d985e1000c29844b01", 4095) = 90
write(2, "Error: could not find libjava.so"..., 33) = 33
write(2, "Error: could not find Java 2 Run"..., 50) = 50
_exit(2)                                



Suggestion:  Have JAVA look for an environment variable to resolve the pathname 
if /proc/self/exe fails.

For comparison, the truss from doing the same thing running Java on Solaris is:

        getustack(0xFFBFF5F4)
        brk(0x00032F08)                                 = 0
        brk(0x00034F08)                                 = 0
        resolvepath("/export/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", "/e
xport/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", 1024) = 53
        sysinfo(SI_ARCHITECTURE, "sparc", 12)           = 6
        resolvepath("/export/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", "/e
xport/home/vobs/jay_unix_java/j2re1.4.2_06/bin/java", 1024) = 53
        access("/export/home/vobs/jay_unix_java/j2re1.4.2_06/lib/sparc/libjava.s
o", 0) = 0
        open("/export/home/vobs/jay_unix_java/j2re1.4.2_06/lib/sparc/jvm.cfg", O
_RDONLY) = 3
        fstat64(3, 0xFFBFE690)                          = 0
        brk(0x00034F08)                                 = 0
###@###.### 11/2/04 04:37 GMT
Comments
EVALUATION -- (4/25/06) After detailed consideration we have decided to close this bug. This is a problem with the virtual environment provided by ClearCase. It is NOT a Java SE bug. We have discussed this issue with a contact in the IBM/Rational ClearCase engineering team and this issue needs to be addressed by the ClearCase product. In other words, we do not believe that applications should be forced to change to workaround deficiencies in the virtualization product. ClearCase today adds a kernel file system module and one possible approach is for it to also provide an application-level interposer library to do the additional work needed to translate paths. We have suggested this approach to our contact in the ClearCase team. In the short term, developers using this product can easily develop their own interposer library that will cause readlink of /proc/self/exe to fail. The java launcher does not require /proc to be present and will fallback to another mechanism when /proc is not present (chroot environments for example). If there are customers uncomfortable about using an interposer library then they should open a service call with IBM/Rational on this issue.
25-04-2006
WORK AROUND -- Another workaround is to use an interposer library that causes the readlink of /proc/self/exe to fail (with ENOENT for example). That is what ClearCase should be doing but isn't. If the launcher cannot read this link then it will use a fallback mechanism and should start-up successfully in ClearCase.
10-04-2006
EVALUATION -- (3/15/06) The java launcher must resolve its own path when re-exec'ing itself. On Linux (since J2SE 5.0) it reads /proc/self/exe which is documented in proc(5) to be a link to the binary that is currently executing. If /proc/self/exe is not present or the link cannot be read then the launcher uses a fallback mechanism to get the path. There are cases where java can be started in a way that makes it harder to get the canonical path of the launcher so the value of the entry in proc is preferable to the fallback mechanism. Now, when running inside ClearCase a process can read /proc/self/exe but due to the virtualization the link value is useless. As /proc/self is a documented interface on Linux this means that any application that reads the exe link will also fail. I assume the issue is that ClearCase cannot deal with mapped files and in that case the right thing is for ClearCase's interposer to cause readlinks of /proc/self/exe to fail. If it did that then the launcher would fallback to another mechanism and java would start. We are consious that some ClearCase users have been impacted by this issue and we are looking into a possible solution.
15-03-2006
WORK AROUND One possible workaround is to disable /proc (e.g. by chroot). We'll fall back to old mechanism if JDK/JVM can't find the entries in /proc. However this won't work before 5.0 though, as there's hard dependency in VM on /proc/self/stat. ###@###.### 2005-07-15 19:17:50 GMT
15-07-2005
EVALUATION The apparent cause for this failure are launcher changes made in Tiger and backported to 1.4.2_05, specifically changes for 4673940. Since at least 1.4.1, the vm and jdk other components have assumed and relied on the availability of a /proc filesystem for the usual sorts of things one does with /proc. When you run java in a chroot jail, you need to include a working version of /proc too, bug 4748127. Therefore, if ClearCase is not properly virtualizing /proc on Linux, the onus of the launch failure would seem to rely more on ClearCase than on Java. ###@###.### 2004-11-12 07:47:03 GMT
02-11-2004