javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Issues related to applications and software problems
Post Reply
Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by Clovis_Sangrail » 2018/05/15 20:09:14

After upgrading from centos 7.4.1708 to Centos 7.5.1804 via yum, I get the following error while trying to run a .jnlp file via javaws:

==========
[T3 ~]$ javaws Downloads/launch.jnlp
Headless check failed. You are forced to run without any graphics. IcedTea-Web can run like this, but your app probably not. This is likely bug in your system.
Headless check failed. You are forced to run without any graphics. IcedTea-Web can run like this, but your app probably not. This is likely bug in your system.
^C[T3 ~]$
==========

The "launch.jnlp" file is generated by the remote console launch command of the IPMI interface to a 1RU server running a SupeMicro X11SSW-F motherboard. Prior to upgrading to 7.5 I was always able to have the IPMI generate the launch.jnlp file, and download it rather than launch it so I could edit the default port numbers to match the redirections through our firewall. I'd then manually run the .jnlp file via the command above, and my console would pop up. Now it fails.

Via yum I rolled back the three java packages:

java-1.8.0-openjdk.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-devel.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.171-7.b10.el7

But it did not fix the problem, I still get the "headless check failed" error with the following java packages:

==========
[T3 ~]$ yum list installed | grep java
java-1.7.0-openjdk.x86_64 1:1.7.0.181-2.6.14.5.el7 @updates
java-1.7.0-openjdk-headless.x86_64 1:1.7.0.181-2.6.14.5.el7 @updates
java-1.8.0-openjdk.x86_64 1:1.8.0.161-2.b14.el7 @base
java-1.8.0-openjdk-devel.x86_64 1:1.8.0.161-2.b14.el7 @base
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.161-2.b14.el7 @base
javapackages-tools.noarch 3.4.1-11.el7 @base
python-javapackages.noarch 3.4.1-11.el7 @base
tzdata-java.noarch 2018e-3.el7 @updates
[T3 ~]$
==========

Tracing javaws though /bin, /etc/alternatives/, and finally to /usr/bin, the javaws being run is /usr/bin/javaws.itweb .

Has anyone else encountered this? Any help is appreciated.
Last edited by Clovis_Sangrail on 2018/05/16 21:06:43, edited 1 time in total.

Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

Re: javaws failure "Headless check failed." After upgrade to 7.5

Post by Clovis_Sangrail » 2018/05/15 23:11:01

I can try to persuade javaws to not fail this "Headless check" via:

=====
[T3 ~]$ export JAVA_TOOL_OPTIONS="-Djava.awt.headless=true"
=====

This makes javaws fail differently:

==========
[T3 ~]$ javaws ./Downloads/launch.jnlp
Picked up JAVA_TOOL_OPTIONS: -Djava.awt.headless=true
Picked up JAVA_TOOL_OPTIONS: -Djava.awt.headless=true
The application's digital signature cannot be verified. Do you want to run the application? It will be granted unrestricted access to your computer.
Name: ATEN Java iKVM Viewer
Publisher: Super Micro Computer, Inc
From:

The digital signature could not be verified by a trusted source. Only run if you trust the origin of the application. The code executed will be given full permissions, ignoring any Java policies you may have.

Type `exit` to terminate ITW, or type one of the below values. Prefix answer by "R " to remember decision and by "RC " to do so for whole codebase.
[YES, NO, SANDBOX]
RC YES
Codebase matches codebase manifest attribute, and application is signed. Continuing. See: http://docs.oracle.com/javase/7/docs/te ... eploy.html for details.
The application <span color='red'> ATEN Java iKVM Viewer (Java viewer ) </span> from <span color='red'> http://{ip}:{port}/ </span> uses resources from the following remote locations: <ul><li>file:/home/kurt/./Downloads</li><li>http://{ip}:{port}</li></ul> Be very careful when application is loading from different space then you expect. Are you sure you want to run this application?
For more information see:
<a href="http://docs.oracle.com/javase/7/docs/te ... brary">JAR
File Manifest Attributes</a>
and
<a href="http://docs.oracle.com/javase/7/docs/te ... Preventing
the Repurposing of an Application</a>

Type `exit` to terminate ITW, or type one of the below values. Prefix answer by "R " to remember decision and by "RC " to do so for whole codebase.
[YES, NO]
RC YES
Buf size:425984
Exception in thread "AWT-EventQueue-2" java.awt.HeadlessException
at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:204)
at java.awt.Window.<init>(Window.java:536)
at java.awt.Frame.<init>(Frame.java:420)
at javax.swing.JFrame.<init>(JFrame.java:233)
at tw.com.aten.ikvm.ui.Viewer.<init>(Unknown Source)
at tw.com.aten.ikvm.KVMMain.run(Unknown Source)
at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:311)
at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:758)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:80)
at java.awt.EventQueue.dispatchEvent(EventQueue.java:728)
at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:205)
at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)
at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
[T3 ~]$
==========

Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

Re: javaws failure "Headless check failed." After upgrade to 7.5

Post by Clovis_Sangrail » 2018/05/16 20:58:23

I removed the java-1.8.0* and icedtea* packages via yum, then installed all the java-1.8.0 packed in the repositories, followed by the three icedtea packages. Now I have:

[T3 ~]# yum list installed | egrep "java-1.8.0|icedtea"
icedtea-web.x86_64 1.7.1-1.el7 @base
icedtea-web-devel.noarch 1.7.1-1.el7 @base
icedtea-web-javadoc.noarch 1.7.1-1.el7 @base
java-1.8.0-openjdk.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-accessibility.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-accessibility-debug.x86_64
java-1.8.0-openjdk-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-demo.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-demo-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-devel.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-devel-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-headless-debug.x86_64
java-1.8.0-openjdk-src.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-src-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
[T3~]#

After this, and without setting the JAVA_TOOLS_OPTIONS environmental I find that I can eventually run the launch.jnlp file. The "javaws Downloads/launch.jnlp" still generates the "Headless check failed" errors, but after hanging for about five minutes it displays the "Codebase matches..." message and prompts. I replied "RC YES", and the remote console successfully launched.

After exiting the javaWS application and running the launch command again, it still threw the "Headless check failed" errors and still hung for several minutes, but then successfully put up the remote console window without prompting me for any responses. The terminal window output is:

==========
[T3 ~]$ javaws Downloads/launch.jnlp
Headless check failed. You are forced to run without any graphics. IcedTea-Web can run like this, but your app probably not. This is likely bug in your system.
OpenJDK 64-Bit Server VM warning: ignoring option PermSize=32M; support was removed in 8.0
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=32M; support was removed in 8.0
Headless check failed. You are forced to run without any graphics. IcedTea-Web can run like this, but your app probably not. This is likely bug in your system.
. . . . . .
. . . . . .
( hangs for about five minutes )
. . . . . .
Codebase matches codebase manifest attribute, and application is signed. Continuing. See: http://docs.oracle.com/javase/7/docs/te ... eploy.html for details.
Buf size:425984
a singal 17 is raised
[T3 ~]$
(Command prompt returns after I close remote console window)
==========

Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

Re: javaws failure "Headless check failed." After upgrade to 7.5

Post by Clovis_Sangrail » 2018/05/16 21:05:02

I downloaded an oracle java 8 .tar.gz file (not the latest, it turns out) from:

http://javadl.oracle.com/webapps/downlo ... eId=207765

and unpacked it into /opt. I find that it's javaws executable can run the .jnlp file without any error messages (or wait):

==========
[T3 ~]$ /opt/jre1.8.0_91/bin/javaws Downloads/launch.jnlp
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=32M; support was removed in 8.0
Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=32M; support was removed in 8.0
[kurt@T3400 ~]$ Buf size:425984
a singal 17 is raised
[T3 ~]$
==========

It looks like the most recent Java 8 SE from Oracle is jre8_u171, at:

http://www.oracle.com/technetwork/java/ ... 33155.html

These workarounds suffice for me in the short term, but I hope that the 'official' javaws can be fixed to run without error messages, like it did in Centos 7.4. I reported this as a bug.

User avatar
TrevorH
Forum Moderator
Posts: 23205
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by TrevorH » 2018/05/16 21:32:37

Why are you using the headless package? My understanding of that was that it was to be used for apps that didn't need a display where, quite obviously, a remote console does need a display. I'd look at the output from alternatives to see what set of java packages are set to be invoked by default. I suspect it's the headless set when you actually want the non-headless version.
CentOS 5 died in March 2017 - migrate NOW!
Full time Geek, part time moderator. Use the FAQ Luke

Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

Re: javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by Clovis_Sangrail » 2018/05/17 14:58:35

That is an interesting question. I don't even know how to tell the "headless" from the regular java. With the exception of a single .so file, he only files installed by the "java-1.8.0-openjdk-headless.x86_64" rpm package that have the text "headless" in the filename are documentation files.

# repoquery --installed -l java-1.8.0-openjdk-headless | grep head
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/lib/amd64/libawt_headless.so
/usr/share/doc/java-1.8.0-openjdk-headless-1.8.0.171
/usr/share/doc/java-1.8.0-openjdk-headless-1.8.0.171/ASSEMBLY_EXCEPTION
/usr/share/doc/java-1.8.0-openjdk-headless-1.8.0.171/LICENSE
/usr/share/doc/java-1.8.0-openjdk-headless-1.8.0.171/THIRD_PARTY_README
#

In fact, I was surprised to find, when I ran the commands:

repoquery --installed -l java-1.8.0-openjdk-headless
repoquery --installed -l java-1.8.0-openjdk

that most of the openjdk content is installed by the 'headless' .rpm, there's only a few files installed by java-1.8.0-openjdk.

This is what the "alternatives" program says about java-related associations. I do not see the above "headless" .so file appearing anyplace in it:

# alternatives --list | egrep "java|jre|jdk"
java auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/bin/java
jre_openjdk auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre
jre_1.8.0 auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre
jre_1.8.0_openjdk auto /usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64
java_sdk_1.8.0 auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64
libjavaplugin.so.x86_64 auto /usr/lib64/IcedTeaPlugin.so
jre_1.7.0 auto /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.181-2.6.14.5.el7.x86_64/jre
jre_1.7.0_openjdk auto /usr/lib/jvm/jre-1.7.0-openjdk-1.7.0.181-2.6.14.5.el7.x86_64
javac auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/bin/javac
java_sdk_openjdk auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64
java_sdk_1.8.0_openjdk auto /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64
#

The program being executed is a .jnlp file launched by the Java Web Start program /usr/bin/javaws.itweb supplied by the icedtea-web packages. That .jnlp file is generated by the IPMI firmware that I am connecting to, and I imagine that which java executables to run are determined by it.

The final "javaws" executable was obviously defined by the 'alternatives' system, yet it does not show up in the above list. Maybe that is part of my problem?

# which javaws
/bin/javaws
# ls -l /bin/javaws
lrwxrwxrwx. 1 root root 24 May 16 15:23 /bin/javaws -> /etc/alternatives/javaws
# ls -l /etc/alternatives/javaws
lrwxrwxrwx. 1 root root 21 May 16 15:23 /etc/alternatives/javaws -> /usr/bin/javaws.itweb
# ls -l /usr/bin/javaws.itweb
-rwxr-xr-x. 1 root root 5530 Apr 11 01:07 /usr/bin/javaws.itweb
#

I have another workstation that I suppose I can reload with Centos 7.4.1708. Or maybe this is the sort of thing that modern sysadmins use VMs for. In any case, thanks for the input.

User avatar
TrevorH
Forum Moderator
Posts: 23205
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by TrevorH » 2018/05/17 15:34:13

Your java auto entry points to a file that says it belongs to the headless package:

Code: Select all

# rpm -qf /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/bin/java
java-1.8.0-openjdk-headless-1.8.0.171-7.b10.el7.x86_64
I can't really check mine to see what it says as I use the Oracle jdk and have told alternatives to use that so my entry reads

java manual /usr/java/latest/bin/java

But yum provides '/usr/lib/jvm/*/*/bin/java' says that only the headless 1.8 packages provide that executable so now I am wondering how you are meant to get a non-headless version to work!

Silly question, I don't suppose yum reinstall java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64 fixes it?
CentOS 5 died in March 2017 - migrate NOW!
Full time Geek, part time moderator. Use the FAQ Luke

Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

Re: javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by Clovis_Sangrail » 2018/05/17 16:03:11

It's true that the pointed-to java executable comes from the 'headless' package, but so does almost all the other java stuff. Here are the only things installed by the 'regular' java-1.8.0.-openjdk:

# rpm -ql java-1.8.0-openjdk
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/bin/policytool
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/lib/amd64/libawt_xawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/lib/amd64/libjawt.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/lib/amd64/libjsoundalsa.so
/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64/jre/lib/amd64/libsplashscreen.so
/usr/share/applications/java-1.8.0-openjdk-1.8.0.171-7.b10.el7.x86_64-policytool.desktop
/usr/share/icons/hicolor/16x16/apps/java-1.8.0.png
/usr/share/icons/hicolor/24x24/apps/java-1.8.0.png
/usr/share/icons/hicolor/32x32/apps/java-1.8.0.png
/usr/share/icons/hicolor/48x48/apps/java-1.8.0.png
[root@T3400 alternatives]# which policytool
/bin/policytool
#

I'll bet that the "headless" package is a dependency for the regular one.

I never did use a "yum reinstall" command, but I did use "yum remove" to remove all the java packages, and the icedtea packages, and then put them back via "yum install".

I think that got me to where the base java packages would eventually run my .jnlp file, after throwing error messages and hanging for 5-odd minutes. But then again, it may be that I just did not wait long enough for it to time out from before I did all that removing and reinstalling.

User avatar
TrevorH
Forum Moderator
Posts: 23205
Joined: 2009/09/24 10:40:56
Location: Brighton, UK

Re: javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by TrevorH » 2018/05/17 16:52:42

I have been wondering if the non-headless package needs to be installed _after_ the headless one and something in the updated versions means it's being installed in the wrong order. No idea if it is true or not but the reinstall would make sure it went in after.
CentOS 5 died in March 2017 - migrate NOW!
Full time Geek, part time moderator. Use the FAQ Luke

Clovis_Sangrail
Posts: 15
Joined: 2016/04/19 23:19:36

Re: javaws failure "Headless check failed." After upgrade to 7.5 (have work-around)

Post by Clovis_Sangrail » 2018/05/17 21:34:44

Well, the short answer is I tried that, and did not see any change in behavior. I had installed a lot of extra java packages from the Centos repos, in the hope that something would fix my issue:

# yum list installed | grep java
icedtea-web-javadoc.noarch 1.7.1-1.el7 @base
java-1.7.0-openjdk.x86_64 1:1.7.0.181-2.6.14.5.el7 @updates
java-1.7.0-openjdk-headless.x86_64 1:1.7.0.181-2.6.14.5.el7 @updates
java-1.8.0-openjdk.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-accessibility.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-accessibility-debug.x86_64
java-1.8.0-openjdk-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-demo.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-demo-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-devel.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-devel-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-headless-debug.x86_64
java-1.8.0-openjdk-src.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-src-debug.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-atk-wrapper.x86_64 0.30.4-5.el7 @base
javapackages-tools.noarch 3.4.1-11.el7 @base
python-javapackages.noarch 3.4.1-11.el7 @base
tzdata-java.noarch 2018e-3.el7 @updates
#

A more reasonable set is this, from a server on which I recently installed Centos 7.5.1804 minimal from DVD and then ran "yum update":

[w ~]# yum list installed | grep java
java-1.7.0-openjdk.x86_64 1:1.7.0.181-2.6.14.5.el7 @updates
java-1.7.0-openjdk-headless.x86_64 1:1.7.0.181-2.6.14.5.el7 @updates
java-1.8.0-openjdk.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-devel.x86_64 1:1.8.0.171-7.b10.el7 @updates
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.171-7.b10.el7 @updates
javapackages-tools.noarch 3.4.1-11.el7 @base
python-javapackages.noarch 3.4.1-11.el7 @base
tzdata-java.noarch 2018e-3.el7 @updates
[w ~]#

So, I removed java-1.8.0*:

# yum remove `yum list installed | grep java-1.8.0 | awk '{ print $1 }'`
Loaded plugins: fastestmirror, langpacks
Resolving Dependencies

. . . . . . . . .

Removed:
java-1.8.0-openjdk.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-accessibility.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-accessibility-debug.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-debug.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-demo.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-demo-debug.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-devel.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-devel-debug.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-headless.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-headless-debug.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-src.x86_64 1:1.8.0.171-7.b10.el7
java-1.8.0-openjdk-src-debug.x86_64 1:1.8.0.171-7.b10.el7
Dependency Removed:
icedtea-web.x86_64 0:1.7.1-1.el7
icedtea-web-devel.noarch 0:1.7.1-1.el7
icedtea-web-javadoc.noarch 0:1.7.1-1.el7

Complete!
#

Then I re-installed java-1.8.0-openjdk-headless , java-1.8.0-openjdk, and icedtea-web in that order, and tried my remote console java web start. It behaved in the same way. It *does* eventually start, and it seems to still remember my "RC YES" response (described above) from yesterday because it does not prompt me for anything, it just hangs for over five minutes after outputting the "Headless check..." errors and before starting.

The manual Oracle Java launch works well enough, I think that is the best I can do for now. I summarized these results in the bug report, hopefully the Centos folk will fix it.

Post Reply