The output of the health_check command in the container is repeated exactly the same way again.
After several hours of searching for the problem, it turned out that it is enough to clear the $(pwd)/ydb_data directory, which was filled due to the first startup with disc storage. After that the problem goes away and a new attempt to run with in-memory storage no longer causes the health_check error.
Given that the warning about the need for M1 processors to use a non-standard command is below the standard command, the risk of running into such a problem is very high.
Configuration:
When attempting to proceed according to instructions if the first attempt to run the container is performed:
The container will come up, but you will not be able to interact with it via the SDK. Executing health_check inside the container:
After that, I noticed a warning in the documentation that to run on M1, you must select the in-memory storage option.
After the second attempt to up the container:
The output of the health_check command in the container is repeated exactly the same way again.
After several hours of searching for the problem, it turned out that it is enough to clear the
$(pwd)/ydb_data
directory, which was filled due to the first startup with disc storage. After that the problem goes away and a new attempt to run with in-memory storage no longer causes the health_check error.Given that the warning about the need for M1 processors to use a non-standard command is below the standard command, the risk of running into such a problem is very high.