Check container's status if WaitStrategy fails.
#1837
Conversation
core/src/main/java/org/testcontainers/containers/GenericContainer.java
Outdated
Show resolved
Hide resolved
| .withCreateContainerCmdModifier(it -> { | ||
| it.getHostConfig().withMemory(4 * FileUtils.ONE_MB); | ||
| }) | ||
| .withCommand("sh", "-c", "usleep 100; dd if=/dev/urandom bs=128GB count=1 > test.txt") |
There was a problem hiding this comment.
Gulp... Better get this right 😅 😂
At first sight I was perplexed as to why writing to disk would cause OOMKill at all, but realised that actually the only thing that matters here is having the blocksize be >4MB, as dd buffers into memory before writing.
If that's the case, could we use > /dev/null or of=/dev/null to just be explicit about blackholing the data?
This might be slightly less alarming for anyone reading the code in future who fears we're about to fill their disk with garbage 😄.
…ner.java Co-Authored-By: Richard North <rich.north@gmail.com>
|
Ohoh, build is failing. Looks like we're not getting OOMKilled like we want to. |
|
@rnorth yeah, will try to debug it (works locally) |
|
Trying to diagnose why this org.testcontainers.containers.GenericContainerTest test is behaving strangely |
On CircleCI there were two problems: * `dd: /dev/urandom: Bad address` when `/dev/urandom` was used, which would cause exit code 1, not the desired OOMKill * Once worked-around, `dd` was only processing a partial block: ``` 0+1 records in 0+1 records out ``` I suspect that `dd` might internally be respecting, or suffering limited buffers due to the cgroup memory limit, though I'm not clear why this behaviour only appeared on CircleCI and Azure pipelines.
rnorth
force-pushed
the
check_status_after_wait
branch
from
6af7c63
to
4f6b7ce
Compare
…wait # Conflicts: # core/src/main/java/org/testcontainers/containers/GenericContainer.java
Fixes #1834