jcmd missing in JRE Alpine images

[madduci]

What are you trying to do?

I try to run jcmd to start a JFR Recording of a running process. Image that i use:

eclipse-temurin:17.0.6_10-jre-alpine

Expected behaviour:

I can launch the tool jcmd and start a recording process.

Observed behaviour:

The tool jcmd isn't available in the image, but jfr is.

Any other comments:

Actually the Java Flight Recorder dump can only be started through the JVM Arguments, but a on-demand start through jcmd isn't possible.

Output of the issue at command line:

> docker run --rm -it --entrypoint /bin/sh eclipse-temurin:17.0.6_10-jre-alpine
/ #  jfr
Tool for working with Flight Recorder files

Before using this tool, you must have a recording file.
A file can be created by starting a recording from command line:

 java -XX:StartFlightRecording:filename=recording.jfr,duration=30s ...

A recording can also be started on already running Java Virtual Machine:

 jcmd (to list available pids)
 jcmd <pid> JFR.start

Recording data can be dumped to file using the JFR.dump command:

 jcmd <pid> JFR.dump filename=recording.jfr

The contents of the recording can then be printed, for example:

 jfr print recording.jfr

 jfr print --events CPULoad,GarbageCollection recording.jfr

 jfr print --json --events CPULoad recording.jfr

 jfr print --categories 'GC,JVM,Java*' recording.jfr

 jfr print --events 'jdk.*' --stack-depth 64 recording.jfr

 jfr summary recording.jfr

 jfr metadata recording.jfr

 jfr metadata --categories GC,Detailed

For more information about available commands, use 'jfr help'
/ # jcmd
/bin/sh: jcmd: not found

Please note that jcmd would be extremely helpful for debugging an application that runs within the Container, based on Alpine.

[RicardoMonteiroSimoes]

Well jcmd is usually only available through the JDK. But I've had problems with the jdk build of your image as well, as in it doesn't have a working jcmd setup. I had to resort to add https://github.com/jattach/jattach to the image to be able to start debugging.

[madduci]

IMHO if the command line tool jfr is in the image and the final build has the flag --enable-jfr, why shouldn't jcmd be there? There's no way to perform an on-demand dump of running processes in containers that use a JRE installation instead of a JDK one, just because the tooling is missing (you can start JFR with a JVM Argument, but what if i want to know exactly when to debug?).

It would be incredibly useful and it wonders me that until now, none has had the issue before.

[RicardoMonteiroSimoes]

Completely agree that it should definitely be there, but it somehow isnt 😛

[sxa]

Noting without further comment that this is not Alpine-specific and the jcmd binary does not exist on other JRE packages. Although if it's not working with the JDK image that would seem to be a bug.

I've had problems with the jdk build of your image as well

@RicardoMonteiroSimoes Have you verified whether this occurs with other providers' Alpine builds?

[madduci]

Any update on this?

[ofir-popowski]

I think this is missing from non-alpine versions as well. I'm using eclipse-temurin:17-jre and jcmd isn't there, while jfr is.

[testn]

Can we fix this?

[sxa]

There are a few points here:

1. I have cheecked and Eclipse Temurin appears consistent with most other distributions in not including jcmd in any JRE downloaded provided
2. The upstream openjdk project is set up to build the JRE through the legacy-jre-image target (our build scripts invokes this). The general recommendation now is that you use jlink to produce your own JRE instead of using a separate JRE, but we are continuing to ship one using the upstream legacy target as a convenience to some of our users and for consistency with other major providers. If you want to explicitly include jcmd in the jlinked runtime then you should be able to add jdk.jcmd to --add-modules parameter of jlink when you invoke it, although I haven't personally tried it.
3. Since Temurin is very much a "vanilla" (unmodified) OpenJDK distribution we would not wish to deviate from upstream in this respect. If you wish to push for a change in behaviour of the legacy-jre-target changed, you should propose that upstream - with the justifications you have given in this issue - at the openjdk project and, if accepted, we would then pick it up by default.