I am working on integration tests for my project a...
# rancher-desktop
g
I am working on integration tests for my project and using Maven as the build system. In the pre-integration-test phase, I spin up a containerized database (using the 23.7.0.0-lite-amd64 version from https://container-registry.oracle.com/ords/ocr/ba/database/free) and shut it down during post-integration-test. This is working as expected so that the build is able to start and stop the container cleanly. I am running a commercial tool that automates the database schema creation. On my MacBook Pro (Intel i9, 32GB) I am running Rancher Desktop 1.18.2 and seeing behavior I cannot explain. When I first start the computer and Rancher Desktop, the schema creation tool connects successfully to the container database, the schema is created, and the tests run successfully. After some builds, the schema creation tool gives me an error saying “invalid username/password”. Without changing anything, I simply do
rdctl shutdown
followed by
rdctl start
and the build starts working again. After a few more builds, the cycle repeats itself and I have to restart Rancher Desktop to get the build working again. Any thoughts on how to track down this problem?
Occasionally, I see errors like this when calling `rdctl shutdown`:
Copy code
WARN[0000] instance "0" has errors                       errors="[host agent is running but driver is not]"
f
The "invalid username/password" error is unlikely to come from Rancher Desktop but from your schema creation tool. I have no idea how to debug that part, as I don't even know what tool it is.
I would check if the Rancher Desktop VM and container engine is still running at that point
What do you get when you run
docker ps
or
docker images
?
g
well…. the tool’s error message might be misleading but it is unable to connect to the database
the VM is running
starting RD allows it to connect again for a dozen or more runs
f
Does
rdctl shell
still work?
g
then it starts failing and restarting RD eliminates the problem
good question, I will try that next time it happens
my guess is yes
f
I wonder if it is maybe failing due to memory pressure; did you try giving the VM more memory and see if it runs for longer that way?
g
that is something I can try. However, there is only either 0 or 1 container running
I have given RD 2 CPUs and 6 GB of RAM
f
That may not be enough depending on your application. It may consume too much memory and the Linux out-of-memory killer may start killing random processes which in turn breaks the base functionality. Worth trying to use more
g
ok