@lgao To get a better picture of the actual system where this is happening, is this RHEL 9 with an UBI8 OpenJDK container?

The container was built from:

FROM registry.access.redhat.com/ubi8/ubi:latest

the host is RHEL 8.5.

(In reply to Lin Gao from comment #2)
> The container was built from:
> 
> FROM registry.access.redhat.com/ubi8/ubi:latest
> 
> the host is RHEL 8.5.

OK, but something must be special to get this kind of setup. I wonder what it is. How do you run the container? How do you run the tests within it? Is there something else involved?

Is it really just this?

on a RHEL 8.5 host:
$ podman run --rm -ti <foo-container>:<tag>
[root@ff7767c0dcb7 /]# mvn clean verify

Would https://gist.github.com/gaol/4d96eace8290e6549635fdc0ea41d0b4#file-podman_container_inspect-json answer it ? :)

which is the meta created by podman inspect, which contains the 'CreateCommand' section on how this container is started.

Not quite, but it'll have to do. I was hoping to understand how those mismatches between mountinfo and /proc/self/cgroup can happen in practise. Either way, there shouldn't be a NPE. I'll bring this bug and fix upstream.

Thanks, and sorry that I have no idea why these mismatches happen.

Maybe the following information can help:

* The full command used to start the podman container:

podman run             --name automaton-slave-eap-7.4.x-testsuite-23 --userns=keep-id -u 1000:1000             --add-host=olympus:10.88.0.1              --rm -v '/home/jenkins/current//jobs/eap-7.4.x-build/builds/28/archive:/parent_job/:ro'                --workdir /var/jenkins_home/workspace/eap-7.4.x-testsuite              -v /home/jenkins/current/workspace/eap-7.4.x-testsuite:/var/jenkins_home/workspace/eap-7.4.x-testsuite:rw -v /opt:/opt:ro              -v /home/jenkins/.ssh/:/var/jenkins_home/.ssh/:ro             -v /home/jenkins/.gitconfig:/var/jenkins_home/.gitconfig:ro             -v /home/jenkins/.netrc:/var/jenkins_home/.netrc:ro             -d localhost/automatons '/var/jenkins_home/workspace/eap-7.4.x-testsuite/hera/wait.sh'



* The podman process:

jenkins   189582       1  0 13:21 ?        00:00:00 /usr/bin/conmon --api-version 1 -c db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f -u db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f -r /usr/bin/runc -b /home/jenkins/.local/share/containers/storage/overlay-containers/db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f/userdata -p /run/user/1000/containers/overlay-containers/db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f/userdata/pidfile -n automaton-slave-eap-7.4.x-testsuite-23 --exit-dir /run/user/1000/libpod/tmp/exits --full-attach -l k8s-file:/home/jenkins/.local/share/containers/storage/overlay-containers/db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f/userdata/ctr.log --log-level warning --runtime-arg --log-format=json --runtime-arg --log --runtime-arg=/run/user/1000/containers/overlay-containers/db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f/userdata/oci-log --conmon-pidfile /run/user/1000/containers/overlay-containers/db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f/userdata/conmon.pid --exit-command /usr/bin/podman --exit-command-arg --root --exit-command-arg /home/jenkins/.local/share/containers/storage --exit-command-arg --runroot --exit-command-arg /run/user/1000/containers --exit-command-arg --log-level --exit-command-arg warning --exit-command-arg --cgroup-manager --exit-command-arg cgroupfs --exit-command-arg --tmpdir --exit-command-arg /run/user/1000/libpod/tmp --exit-command-arg --runtime --exit-command-arg runc --exit-command-arg --storage-driver --exit-command-arg overlay --exit-command-arg --events-backend --exit-command-arg file --exit-command-arg container --exit-command-arg cleanup --exit-command-arg --rm --exit-command-arg db5b6c6e60784e6c9b743bafb7f55abb86836b6f346d3d8ff5e739b9409f185f



* The process inside the container to run the tests:

jenkins       96      43  0 05:21 pts/0    00:00:01 /opt/oracle/jdk-17.0.2/bin/java -Dmaven.wagon.http.ssl.insecure=true -Dhttps.protocols=TLSv1.2 -Xmx2048m -Xms1024m -Dmaven.wagon.http.pool=false -Dmaven.wagon.httpconnectionManager.maxPerRoute=3 -classpath /var/jenkins_home/workspace/eap-7.4.x-testsuite/workdir/.mvn/wrapper/maven-wrapper.jar -Dmaven.home=/var/jenkins_home/workspace/eap-7.4.x-testsuite -Dmaven.multiModuleProjectDirectory=/var/jenkins_home/workspace/eap-7.4.x-testsuite/workdir org.apache.maven.wrapper.MavenWrapperMain -Dmaven.user.home=/var/jenkins_home/workspace/eap-7.4.x-testsuite/workdir/tools install -DallTests -fae -fae -Delytron -DnoCompile -Dsurefire.forked.process.timeout=90000 -Dskip-download-sources -B -Dmaven.test.failure.ignore= -Dsurefire.rerunFailingTestsCount=0 -Dsurefire.memory.args=-Xmx1024m -s /opt/tools/settings.xml

Issue migration from Bugzilla to Jira is in process at this time. This will be the last message in Jira copied from the Bugzilla bug.

This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there.

Due to differences in account names between systems, some fields were not replicated.  Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information.

To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "RHEL-" followed by an integer.  You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like:

"Bugzilla Bug" = 1234567

In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information.