Description of problem: Openjdk 11 update 11.0.4.11-0 did oft correct links in /etc/alternatives, which led to a system failure i.e. with Tomcat on restart/reboot. Very unfortune in a production server :( 2019-08-04T08:01:33Z SUBDEBUG Upgrade: java-11-openjdk-headless-1:11.0.4.11-0.fc29.x86_64 2019-08-04T08:01:41Z SUBDEBUG Upgrade: java-11-openjdk-headless-1:11.0.4.11-0.fc29.x86_64 2019-08-04T08:01:41Z INFO Warnung: /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/default.policy erstellt als /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/default.policy.rpmnew Warnung: /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/public_suffix_list.dat erstellt als /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/public_suffix_list.dat.rpmnew 2019-08-04T08:01:53Z INFO restored /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/default.policy.rpmnew to /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/default.policy restored /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/public_suffix_list.dat.rpmnew to /etc/java/java-11-openjdk/java-11-openjdk-11.0.4.11-0.fc29.x86_64/lib/security/public_suffix_list.dat 2019-08-04T08:01:53Z SUBDEBUG Upgrade: java-11-openjdk-1:11.0.4.11-0.fc29.x86_64 2019-08-04T08:01:53Z SUBDEBUG Upgrade: java-11-openjdk-1:11.0.4.11-0.fc29.x86_64 2019-08-04T08:01:53Z SUBDEBUG Upgraded: java-11-openjdk-1:11.0.3.7-1.fc29.x86_64 2019-08-04T08:01:53Z SUBDEBUG Upgraded: java-11-openjdk-1:11.0.3.7-1.fc29.x86_64 2019-08-04T08:01:53Z SUBDEBUG Upgraded: java-11-openjdk-headless-1:11.0.3.7-1.fc29.x86_64 2019-08-04T08:01:53Z SUBDEBUG Upgraded: java-11-openjdk-headless-1:11.0.3.7-1.fc29.x86_64 2019-08-04T08:01:53Z INFO /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64/bin/java wurde nicht als eine Alternative für java konfiguriert /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64 wurde nicht als eine Alternative für jre_openjdk konfiguriert /usr/lib/jvm/java-11-openjdk-11.0.3.7-1.fc29.x86_64 wurde nicht als eine Alternative für jre_11 konfiguriert Warnung: %postun(java-11-openjdk-headless-1:11.0.3.7-1.fc29.x86_64) Scriptlet fehlgeschlagen, Beenden-Status 2 2019-08-04T08:01:53Z ERROR Error in POSTUN scriptlet in rpm package java-11-openjdk-headless "wurde nicht als eine Alternative für ... konfiguriert " means "did not get configured as an alternative for ..." without the "alternatives"-links, java was inaccessible. on a second server, the update was applied correctly. Version-Release number of selected component (if applicable): java-11-openjdk-headless-1:11.0.4.11-0.fc29.x86_64 How reproducible: "dnf update" was enough to trigger the problem. A "dnf reinstall java-11-*" fixed it.
Is this reproducible? If so how frequently (percentage)?
2 servers running Java 11, 1 had have no problems, 1 failed. The rest has 1.8 installed, which seemed to work fine. A small update for the fix: dnf reinstall java-11* did work in general, BUT failed to link the correct JRE paths. The script did not set i.e. jre_11 and jre_11_openjdk at all, and it did not fix "jre" nor "jre_openjdk". But it set the rest of the alternatives links correctly. Unfortunatly, i don't have any other Java 11 servers to test it. and, in general, it seems to be a bad idea to have java 8 and 11 together on one system, mainly because of the alternatives links. BTW: as you on it, why did the server got a java-latest-openjdk-12* installed? java-11-openjdk-headless-11.0.4.11-0.fc29.x86_64 java-latest-openjdk-12.0.2.9-1.rolling.fc29.x86_64 java-openjdk-12.0.0.33-4.rolling.fc29.x86_64 java-latest-openjdk-headless-12.0.2.9-1.rolling.fc29.x86_64 java-11-openjdk-11.0.4.11-0.fc29.x86_64 Could those be in conflict over the alternative links?
(In reply to customercare from comment #2) > 2 servers running Java 11, > 1 had have no problems, > 1 failed. > > The rest has 1.8 installed, which seemed to work fine. Right. But if you were to install an old version of the package, java-11-openjdk 11.0.3, say, and run an update, does it reproduce? I'm guessing not. We don't have a clear reproducer for this issue. > > A small update for the fix: > > dnf reinstall java-11* did work in general, > BUT failed to link the correct JRE paths. > > The script did not set i.e. jre_11 and jre_11_openjdk at all, > and it did not fix "jre" nor "jre_openjdk". > But it set the rest of the alternatives links correctly. This is probably bug 1200302 (reinstall breaks alternatives). I'd suggest to remove and install it again. > Unfortunatly, i don't have any other Java 11 servers to test it. > > and, in general, it seems to be a bad idea to have java 8 and 11 together on > one system, > mainly because of the alternatives links. No. If both, JDK 8 and JDK 11, are installed JDK 8 will be the default java via alternatives. If you'd like to switch, set the alternatives links manual via (JRE): alternatives --config java (JDK): alternatives --config javac > BTW: as you on it, why did the server got a java-latest-openjdk-12* > installed? > > java-11-openjdk-headless-11.0.4.11-0.fc29.x86_64 > java-latest-openjdk-12.0.2.9-1.rolling.fc29.x86_64 > java-openjdk-12.0.0.33-4.rolling.fc29.x86_64 > java-latest-openjdk-headless-12.0.2.9-1.rolling.fc29.x86_64 > java-11-openjdk-11.0.4.11-0.fc29.x86_64 I don't know how you got into this state. But right now java-openjdk package has been retired and replaced by java-latest-openjdk. Your installed version of java-openjdk (12.0.0.33-4.rolling) is an empty package with only a dependency on java-latest-openjdk. If you don't need them, I suggest to remove them both. If you need a JDK 12, first remove java-openjdk (which should in turn remove java-latest-openjdk as an unused dep), then install java-latest-openjdk. > > Could those be in conflict over the alternative links? No. With both, java-latest-openjdk and java-11-openjdk installed, JDK 11 will take higher precedence.
I'm sorry to say this, but I will not try it on that server, as it is a production service and had have enough offline times for now. I will do some checks on a different system and let you know. The service does not need Java 12 as far as i know. Thanks for the advice, i will remove it.
*** This bug has been marked as a duplicate of bug 1200302 ***