LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   Unable to get Sun's Java to work in a chroot at all: no output from javac, etc. (https://www.linuxquestions.org/questions/linux-software-2/unable-to-get-suns-java-to-work-in-a-chroot-at-all-no-output-from-javac-etc-598634/)

HowDoIProgramIt 11-10-2007 01:47 PM

Unable to get Sun's Java to work in a chroot at all: no output from javac, etc.
 
Hi, all. For me, this is yet another round of frustration with Java; I've hit a dead end here...

I've been trying to get java - not even a fancy app, at this point, I would be happy if I could get the basic tools, like "javac", to work. I'm using a GNU/linux system - I've tried several but am currently focusing on a 64-bit, multilib, Debian/etch system on which I created a 32-bit "lenny" chroot using "debootstrap". "Etch" is running on one of my more poweful workstations; I wanted to work on developing a very customized 32-bit linux distribution on that workstation. I realize I have other choices; however, and a chroot seemed like a good way to do it at the time, and at this point, if nothing else, I would like to understand why, to date, it has refused to work.

The chroot has a /proc, and a /dev, etc. that it gets from a bind mount; it has its own /etc/hosts && /etc/passwd && /etc/group, and so on. I can install software via apt or manually; I can build, run, etc. 32-bit apps; in fact, everything seemed to be working fine. That is, until I install java and tried to use it.

Inside the chroot, in /opt, I chmod'd the jdk 1.6 .bin file and ran it. I got several screenfulls of license info, to which I said "yes". The installer then continued, and ultimately created a directory "/opt/jdk1.6.0_03" (which contains bin, lib, jre, etc.). I chroot'd into the chroot I created, then set PATH so it began with /opt/jdk1.6.0_03/bin & exported PATH; I set JAVA_HOME to /opt/jdk1.6.0_03 and exported it, too. However, when I run javac - "javac -version" - I get nothing at all. Just another command prompt. I've tried setting my cwd to /opt/jdk1.6.0_03/bin and running ./javac -version, nothing. I've verified (with "which") that this was the only javac on my PATH. If I give javac the name of a .class file as input it still does nothing. No output - including no error messages - none to the console, none in system logs, etc.

I've run strace (strace -f javac -version) on this machine, and on a pure 32 bit installation of Linux on a different machine. The results are quite different (some of the differences are attributable to kernel version differences; what's obviously different about the two is that one starts worker threads that do something, while the other doesn't). I've checked the PIDs of the child processes reported by strace on the machine on which javac doesn't apparently work; I don't see them as root in "ps auxw" (eg., they're not showing up as zombied, etc.)

Inside the chroot, LD_LIBRARY_PATH is "", PATH is what debootstrap set it to + the change I made to include /opt/jdk1.6.0_03/bin, etc. I did install the locale package inside the chroot as several apps were complaining about its absence, along with any other packages that were "obviously" missing (ssh-client, for example; I didn't have ssh, scp, sftp, etc.).

As it's a "multilib" system, I did try setting PATH and JAVA_HOME as above and running javac; I got exactly the same results there as I did when I tried running javac, etc. from inside the chroot. I found a note regarding java-in-chroots in Sun's docs, and verified that my /proc setup was acceptible in that respect. I've spent at least the last week going through various tips, etc. on the web - tutorials regarding how to set up BIND, apache, etc. - and I'm no further along now as far as java is concerned than I was when I started.

At this point, I'm at a complete loss. I'm actually not even sure what the next thing to try to get this to work is. About the only thing that's apparent to me is that javac (or a library on which it depends, etc.) is looking for something that either isn't there or isn't configured either correctly or the way it would like it to be. It wouldn't surprise me at all if this turned out to be something relatively simple. It may be something in the setup of the chroot jail; or, it may be something specific to java (eg., some resource it wants / needs which it isn't getting). As the system I'm working on is a Debian system, I followed the instructions in "http://www.debian.org/doc/manuals/reference/ch-tips.en.html#s-chroot" - again, everything but java/"javac" works fantastically.

Whatever it is, I'm just not seeing it. I should be able to set up a chroot and run application(s) in it, independent of what's installed on the host, right? Eg., it shouldn't matter what's installed on the host - what version, 32 or 64 bit, etc.; an app in the chroot should only ever "see" what's installed in the chroot. Right? (notwithstanding the known security problems, etc. associated w chroot jails, etc. ...) One thing I'm still a bit unclear on is how the host system affects the chroot in some respects: some of the tutorials, etc. directed the reader to add, to the main system /etc/ld.so.conf, the paths that the chroot's /etc/ld.so.conf should have in it. Since the chroot has its own (and its own dynamic loader), why is this / would this be?

Am I correct in the assertion that it should be possible to create a generic template (in the form of a shell script, etc.) for a chroot jail on a Linux system (differences from one distribution to another notwithstanding) or am I missing something fundamental here?

Thanks. If someone could help me get this to work, I would really appreciate it. One last thing I should probably mention is that the machine I'm working with isn't 100% stock Debian - for example, it's running a 2.6.23 kernel - it's been close enough for every other purpose I've encountered to date, though. Aside from the obvious problem of Java not working, I'm growing increasingly concerned that there's a larger problem here (eg., that there's something awry with my overall configuration, or that I'm fundamentally misunderstanding something w/ respect to chroot jails, etc.).

- Larry

unSpawn 11-11-2007 05:09 PM

Could you upload the strace logs for the chrooted and not chrooted 'javac -version' somewhere?

HowDoIProgramIt 11-11-2007 09:24 PM

Quote:

Originally Posted by unSpawn (Post 2955609)
Could you upload the strace logs for the chrooted and not chrooted 'javac -version' somewhere?

Actually, I think I remembered everything but the URLs for the logs ;(

They're at:
http://www.cslimits.org/strace-working.txt
http://www.cslimits.org/strace-not-working.txt

Please let me know if there's anything else you can think of that'd be helpful. Thanks.

- Larry

unSpawn 11-13-2007 03:04 PM

Weird since you said you installed it inside the chroot (unless you didn't actually chroot in before running the installer). The strace of the non-working chrooted javac, up to where it halts, looks quite similar to the "regular" strace. I had a quick go at chrooting a j2re myself last night and I found I couldn't move it over flawlessly with all the dependencies in one go. What I ended up doing was making a chrootdir, copying over j2re, bash and strace files from the regular system, bind-mounting dev and proc, then chrooting in and stracing it until it again hit a lib or config it couldn't find, ad nauseam.

Instead of chipping at it with strace until you eventually get all deps, how about using 'debootstrap' on a clean dir and adding packages you need with the "--include=" switch?

HowDoIProgramIt 11-13-2007 10:04 PM

Wow, this is a doozy...

Quote:

Originally Posted by unSpawn (Post 2957855)
Weird since you said you installed it inside the chroot (unless you didn't actually chroot in before running the installer).

"Wierd" is a good word for this (though it's not the one I've been uttering lately regarding this). I'm positive I chroot'd into the jail before I ran the installer; at one point, I started from scratch (eg., created a new chroot jail, bootstrapped it, chroot'd into it, and attempted to install the JDK).

Quote:

The strace of the non-working chrooted javac, up to where it halts, looks quite similar to the "regular" strace. I had a quick go at chrooting a j2re myself last night and I found I couldn't move it over flawlessly with all the dependencies in one go. What I ended up doing was making a chrootdir, copying over j2re, bash and strace files from the regular system, bind-mounting dev and proc, then chrooting in and stracing it until it again hit a lib or config it couldn't find, ad nauseam.
I really appreciate your time and efforts. "Thank you" very much.

That was the conclusion I'd come to; I didn't see any differences that weren't due to kernel API changes, etc. between the two strace dumps.

I've run a number of test programs to test various aspects of threading on the mahine on which I'm having this problem; I haven't yet been able to get anything using fork(), or POSIX pthread_xxx calls, to not work.
Quote:

Instead of chipping at it with strace until you eventually get all deps, how about using 'debootstrap' on a clean dir and adding packages you need with the "--include=" switch?
Actually, I used debootstrap to set up this particular chroot jail. So far, I've tried setting the jail up both manually and with debootstrap, same results each time.

I also tried building the jail using components I built from source; I have several "roll yer own" type systems / linux verisons we use for special purpose machines: embedded systems and the like. I realize this was grasping but since it looked from the strace that the child threads died almost immediately after they started, and that they appeared to have started without error I thought perhaps we might be seeing the result of a strange, well hidden, bug in one of the system libraries, etc. Apparently not though since "javac" did exactly what it had done in a jail created w deboostrap.

At this point I'm not even sure what to try next; I'm open to suggestions though.

Thanks again for your time and your efforts, I really appreciate it.

- Larry

unSpawn 11-16-2007 08:01 AM

Another way may be to make an image of a system that "just works" and use virtualisation?

HowDoIProgramIt 11-17-2007 09:00 AM

Quote:

Originally Posted by unSpawn (Post 2960947)
Another way may be to make an image of a system that "just works" and use virtualisation?

Yeah, that's what I've been doing; I haven't been able to figure out what the heck is going on with the java tools... The problem's actually worse than what I had originally thought; I've seen installs of two different distributions (they're both machines that were set up by and are used by other persons) where - I'm not going to say they do the same thing as I'm not even sure what, exactly, is happening occurring in the chroot environment I've been trying to get up and running, but - the net result is the same: no output from "javac -version" (or javac <anything>), etc. As far as I can tell from the strace, they're doing the same thing up to the point where the trace ends; as suspicious as that is, it's not really evidence of anything though.

What's even worse still is that in all cases is that the java plugin trashes the browser in these instances, too. I set up a 32-bit browser in the chroot jail we've been discussing; the other distros had browsers installed already. They all work fine until a page with a java applet on it is loaded, at which point, the browser locks up hard (screen won't redraw, etc.).

Curiously, around the same time this all started occurring, I began seeing an error message from glibc to the effect that it had detected memory corruption, either somehow related to malloc, or a "corrupted doubly linked list". The apps involved were all using embedded mozilla in some way, size, shape or form, and in all cases, the error message went away after I rebuilt them linked against XULRunner.

I'm not sure if the java problems and that issue are related - I still haven't determined exactly what the other issue is - but I wouldn't be at all surprised if the two were related. There are currently a number of nasty little "gotcha"s in GNOME (and possibly Gtk, etc.) that will hopefully be caught and fixed; at the point at which they are, it wouldn't surprise me if everything started to "just work" again.

In the meantime ... Thanks again for your time and your help, I really appreciate it. If I ever do come up with something definite, I'll pass it along.

- Larry


All times are GMT -5. The time now is 06:31 AM.