-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Integration tests sometimes hang #134
Comments
On newer distros, Temporary (until reboot) fix: sudo mkdir /sys/fs/cgroup/systemd
sudo mount -t cgroup -o none,name=systemd cgroup /sys/fs/cgroup/systemd "Permanent" (undoable) fix: $ sudo dnf install -y grubby
$ sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=0"
$ sudo reboot After a fix is applied, |
Actually, an even better invocation for repeatedly running the tests but without running a full rebuild:
|
After applying the kernel cgroup change and rebooting to test this, I'm no longer seeing hangs with podman. Docker also works perfectly with the cgroup change. @ebaron would you mind trying this out too? |
I still saw this with podman. Tried the following:
|
I was also able to reproduce the hang after booting the kernel with |
Hmm. Did you use Docker or still with Podman? I don't know what effect, if any, those fixes have on Podman, but they allow Docker to run on F31. Otherwise I got some "cgroup mount" error when trying to run anything with Docker. Are you getting it to hang every time with Podman or is it also intermittent for you? |
It's intermittent with Podman, I'll try with Docker. |
Okay, did 50 runs with Docker and no hang. |
Thanks for testing that. I'll close this then since this really seems to be an issue with podman, maybe the same or related to containers/podman#4621 |
When running
mvn clean verify
, or something like it, the build sometimes gets stuck and seems to hang on a pre-integration-test step. The issue appears to be with the exec plugin when attempting to start the container using podman. This uses a synchronous exec plugin configuration but gives the--detach
flag to podman, so the podman process should be exiting after the container has been spun up. It seems that sometimes either podman doesn't exit, or somehow the exec plugin doesn't see that it has. When this happens,podman ps -a
can be used to observe that the container does in fact exist and is running. However,podman kill container-jfr-itest
typically complains about a "device or resource busy", although it still seems to succeed in killing and removing the container anyway.The text was updated successfully, but these errors were encountered: