###@###.### 2002-12-09
javac fails with the following error when compiling under chroot enviroment:

$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac hello.java
Alarm Clock
$ uname -a
SunOS cpr-bld 5.8 (on28_108528-10 chroot) sun4u sparc SUNW,Ultra-Enterprise

Note1:

same command works well in a non chroot environment:

$ uname -a
SunOS cpr-bld 5.9 on81-raf:02/17/02 sun4u sparc SUNW,Ultra-Enterprise
$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac hello.java
$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/java hello
main, starting ...
hello !!
$


Note2: this problem does happen often, but not always.

Note3: might be related to NFS ? the problem *seems* to happen when javac is taken from a NFS location, not when javac is taken from local file system

Note4: might be related to chroot ? I only saw this problem under chroot environment.

###@###.### 2003-01-09
I'm copying Fred Oliver's email sent to me on Dec. 13th 2002 for information:
Ken,

I've tried running javac from an NFS mount point. I've still not
been able to reproduce the problem. (Solaris 8)

Note that I am giving mount commands by hand, rather than depending
on the automounter:

# mount -F nfs american:/export/dist /files1/root/mnt
# chroot /files1/root /mnt/share/java,v1.3.1_02/5.x-sun4/bin/javac Hello.java

Can you test that?

------

Are you seeing the errors when the chroot'd environment is the same
version of Solaris as the kernel runs? Please test that specifically.

This is important, because, as mentioned on the web page you referred
to, the kernel and certain user code are tightly coupled. libthread
is specifically mentioned on that page, and the JVM is very tightly
coupled to libthread. (You don't want to know how many bugs in
libthread became visible in java.)

There are other areas where version skew might cause problems,
including NFS (interfaces between kernel I/O and NFS daemons).

The JVM tests the kernel for features directly, rather than using
uname(). For example, it uses mmap and memcntl to check for Solaris 9
MPSS large page support. I don't expect that using MPSS (because the
kernel is Solaris 9) in a Solaris 8 chroot environment should cause
a problem.

Fred

To follow-up on Fred Oliver's request for further information, I have
performed some more tests, which I summarize below.

There seem to be some NECESSARY conditions to reproduce this problem
(ie we can never repdroduce the problem without them all):
 1. use of javac using an NFS path (/usr/dist/share/java...) on another host
 2. use of a chroot command that resets / to a Solaris 8 root
 3. use of javac v1.3.1_02 (/usr/dist/share/java,v1.4.0... does not fail)

Some case tests are described below:
Frequency Context
sometimes skull.france, using chroot ref28 (s28s_u7wos_08a build).
often (70%) in Dec. 2002
rarely (10%) on Jan. 9 2003 (seemed to occur more frequently with -verbose)
often (70%) cpr-bld.uk using chroot on28 (s28s_u4wos_08 build)

never skull.france using chroot ref29 (s9_58shwpl3 build)
never cpr-bld.uk using chroot on81 (s9_54 build)
never when not using chroot
never when using a local host version of javac

Note the problem does not occur under a chroot S9 when the host is running S9.
On cpr-bld.uk, I also made some calls with the -verbose option, which may
indicate when the Alarm Clock error occurs:
/usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac hello.java
bash-2.03$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac -verbose hello.java
[parsing started hello.java]
Alarm Clock
bash-2.03$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac -verbose hello.java
[parsing started hello.java]
[parsing completed 198ms]
Alarm Clock
bash-2.03$ /usr/dist/share/java,v1.3.1_02/5.x-sun4/bin/javac -verbose hello.java
[parsing started hello.java]
[parsing completed 201ms]
Alarm Clock

FINAL NOTE: Note that I don't test the mount manually as Fred describes.
Fred does the chrooting to an NFS root, whereas
I'm chrooting to a directory on the host, then calling /usr/dist/.../javac
from within the created shell. The chroot environment is setup as follows:

        exec /usr/sbin/chroot /share/chroot/$subdir /usr/bin/su - ${LOGNAME}${CFLAG:+ -c "${CFLAG}"}

where /share/chroot/on28 is for example the S8 build directory.