Bug 1732514 - stap java probing missing req: runtime subrpm needs java-devel
Summary: stap java probing missing req: runtime subrpm needs java-devel
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: systemtap
Version: 8.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: 8.1
Assignee: Frank Ch. Eigler
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks: 1755788
TreeView+ depends on / blocked
 
Reported: 2019-07-23 14:16 UTC by Lukas Berk
Modified: 2019-11-05 20:55 UTC (History)
4 users (show)

Fixed In Version: systemtap-4.1-6.el8
Doc Type: No Doc Update
Doc Text:
Clone Of:
: 1755788 (view as bug list)
Environment:
Last Closed: 2019-11-05 20:55:09 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2019:3366 None None None 2019-11-05 20:55:17 UTC

Description Lukas Berk 2019-07-23 14:16:44 UTC
Description of problem:
A number of assumptions and dependencies built into the systemtap java probing runtime fail on el8 era hosts.  Specifically:

- the `jps` tool being available through the jpackage-utils package
- JAVA_HOME environment variable default pointing to the active java version
(/usr/lib/jvm/java dir doesn't exist after `yum install systemtap-runtime-java`)

Most of these changes probably stem from the java runtime/sdk being shipping in the form of modules now.  It might be as simple as adding a (runtime) dependency on java-devel, which seems to fix a variety of the issues above (jps is installed, and the JAVA_HOME dir properly populated)

Version-Release number of selected component (if applicable):
systemtap-runtime-java-4.1-3.el8.x86_64

How reproducible:
Always

Steps to Reproduce:
1. yum install systemtap-runtime-java
2. try to run java probes
3.

Actual results:


Expected results:


Additional info:

Comment 1 Severin Gehwolf 2019-07-26 17:31:26 UTC
(In reply to Lukas Berk from comment #0)
> Description of problem:
> A number of assumptions and dependencies built into the systemtap java
> probing runtime fail on el8 era hosts.  Specifically:
> 
> - the `jps` tool being available through the jpackage-utils package
> - JAVA_HOME environment variable default pointing to the active java version
> (/usr/lib/jvm/java dir doesn't exist after `yum install
> systemtap-runtime-java`)
> 
> Most of these changes probably stem from the java runtime/sdk being shipping
> in the form of modules now. 

Does it? yum install systemtap-runtime-java brings in java-1.8.0-openjdk-headless for me.
Only JDK 9+ have JPMS (Java Platform Module System). Has it been tested with JDK 11 at all?
As far as byteman in RHEL-8 is concerned it's new enough to be used with a modular JDK.

> It might be as simple as adding a (runtime)
> dependency on java-devel, which seems to fix a variety of the issues above
> (jps is installed, and the JAVA_HOME dir properly populated)

Yes. It appears a runtime dependency on java-devel is missing.

"jps" is *not* part of jpackage-utils (or javapackages-tools these days). It's part of
java-X-openjdk-devel packages.

If systemtap-runtime-java sets JAVA_HOME to be /usr/lib/jvm/java it has an implicit dependency 
on the java_sdk alternatives link which is a slave of javac, itself part of -devel subpackage.

Comment 5 Frank Ch. Eigler 2019-07-30 14:19:07 UTC
Got it, thanks.  I misinterpreted your "Note that java-11-openjdk packages don't provide version-less virtual provides, like 'java-devel'." to suggest that -no- openjdk packages provide 'java-devel'.

commit 16bf9d37fe22

Comment 14 Martin Cermak 2019-10-01 14:15:01 UTC
Verified with systemtap-4.1-6.el8: systemtap-runtime-java now requires java-devel.

Comment 16 errata-xmlrpc 2019-11-05 20:55:09 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/RHEA-2019:3366


Note You need to log in before you can comment on or make changes to this bug.