Bug 1319875

Summary: Running JDKs are affected by moving JVM installation directories
Product: Red Hat Enterprise Linux 7 Reporter: Andrew John Hughes <ahughes>
Component: java-1.8.0-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED ERRATA QA Contact: Lukáš Zachar <lzachar>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 7.2CC: ahughes, dbhole, isenfeld, jvanek, jwright
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: java-1.8.0-openjdk-1.8.0.121-6.b14.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1450471 (view as bug list) Environment:
Last Closed: 2017-08-01 08:46:49 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1390370, 1450471    

Description Andrew John Hughes 2016-03-21 17:55:01 UTC 
If the JDK is updated while an instance of the JVM is running, the JVM can lose access to files it needs to use, as the updated JVM is installed in a differently named directory, due to the changed Name-Version-Release triple (NVR).

This is particularly noticeable with the cacerts database, as is loaded multiple times (see bug 8129988: JSSE should create a single instance of the cacerts KeyStore [0]). If a running JVM tries to load the cacerts file after a JDK update, the old cacerts file will no longer exist as it is referenced as java.home/jre/lib/security/cacerts, where java.home includes the full NVR.
This is visible in the CentOS bug, 9088.

As cacerts is actually just a symlink to /etc/pki/java/cacerts, we could fix the JDK to look to this location first, in the same way that the default.sf2 symlink was replaced by direct access to the soundfont [2].

We can try proposing this to upstream OpenJDK as well, but, given their reactions to doing a similar thing with the timezone database, it seems unlikely it would be accepted, so this may have to be kept as a local fix, at least until S8129988 is fixed.

[0] https://bugs.openjdk.java.net/browse/JDK-8129988
[1] https://bugs.centos.org/view.php?id=9088
[2] https://bugs.openjdk.java.net/browse/JDK-8140620
Comment 2 Deepak Bhole 2016-06-20 19:13:34 UTC 
Deferring to 7.4
Comment 3 Andrew John Hughes 2016-06-21 03:37:22 UTC 
FWIW, this is ready to go.
Comment 4 jiri vanek 2016-06-21 09:47:28 UTC 
Hi Andrew, also jdk7 is probably affected by this bug. Is the fix applicable?
Comment 5 Andrew John Hughes 2016-06-21 17:15:06 UTC 
It's already fixed in all three release streams of IcedTea:

* PR2890, 1.13.11 (http://bitly.com/it11311)
* PR2889, 2.6.6 (http://bitly.com/it20606)
* PR2888, 3.0.0 (http://bitly.com/it30000)

which means the java-1.6.0-openjdk and java-1.7.0-openjdk packages already picked this up across all RHELs with the April updates. It's just missing from java-1.8.0-openjdk because it doesn't use IcedTea.
Comment 6 Andrew John Hughes 2016-06-21 17:21:00 UTC 
Incidentally, that does mean we should also file one for RHEL 6.9, but I was waiting for progress on this one.
Comment 9 Andrew John Hughes 2017-03-01 03:01:08 UTC 
This bug has not yet been fixed in the RPM.
Comment 11 jiri vanek 2017-03-01 10:36:49 UTC 
Is there anything more ten this?
http://icedtea.classpath.org//hg/icedtea8-forest/jdk?cmd=changeset;node=3334efeacd83
Comment 15 errata-xmlrpc 2017-08-01 08:46:49 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1831