From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050524 Fedora/1.0.4-4 Firefox/1.0.4 Description of problem: This problem is not so easy to describe--in fact, I don't really know if it should be classified as an httpd or java bug, or not a bug at all. But we lost a lot of time to track down what happened, so this might be useful to someone else. The story: we run some distributed software on Fedora since a while. One of the things we do is to give to the JVM an option like -Djava.policy=http://example.com/policy to download from a web server a policy file, granting suitable permissions. We upgraded our boxes from Fedora 1 to Fedora 4, and everything stopped working, with Java complaining about permission errors. After a lot of debugging and stracing, it turned out that the upgrade turned on IPV6 automatically. However, the *web server* (Apache) was not IPV6-enabled. As a result, Java was detecting the existence of IPV6 and trying to open the web server using IPV6, with no results. Of course we could claim this is a Java bug (they should fall back to IPV4). But it was very complicated to diagnose the problem anyway. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Try to start a JVM using an http://-based policy file, but pointing at a standard httpd installation (which does not activate IPV6). Looking at the access logs, you'll see that the file is not accessed. If your Java code does something requiring permissions that are not granted usually, it will break. Actual Results: The policy file is never accessed. Expected Results: The policy file should have been downloaded. Additional info: Just disable IPV6 and everything works fine again.
One thing I forgot: this happens with Sun's JVM (1.4.2 and 1.5.0), but does *not* happen with JRockit (which probably falls back to IPV4, or maybe it is not IPV6-enabled at all).
You need to track down more precisely what the problem was. This could be a resolver issue, a network issue, a Java issue, pretty much anything. httpd will, in the default configuration, accept connections to port 80 on any IPv4 or IPv6 address on any configured interface.
OK, this is the magic point in the strace log where java breaks: socket(PF_INET6, SOCK_STREAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET6, sin6_port=htons(80), inet_pton(AF_INET6, "::ffff:159.149.146.233", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, 24) = -1 EINVAL (Invalid argument) close(3) Running the same stuff without IPV6, in the corresponding strace position we get: socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3 connect(3, {sa_family=AF_INET, sin_port=htons(80), sin_addr=inet_addr("159.149.146.233")}, 16) = 0 and then everything works fine.
If that's a strace of the JVM, then that's a JVM bug. EINVAL means that connect has been called incorrectly in some way, my money is on the fact that sizeof(sockaddr_in6) is 28 not 24 as used in the third argument to the system call.