When running Docker containers on your local machine, they by default have almost unlimited resources. On sloppy.io, you only pay for the resources you need, but that also means that each app (=container) has strict resource limitations.
The most common issue related to that is containers running out of memory. When that happens, processes often crash with an exit code 137. While there are no standards for the meaning of exit codes, this one pretty reliably indicates a memory issue.
To simulate the memory-restricted environement, we can launch a container locally using the
--memory-swap docker-run options:
docker run -m 128m --memory-swap=128m -e MYSQL_ROOT_PASSWORD='pw' mysql
In this example, we would launch the official mysql image with a limit of 128 MB, and no swap space (setting memory-swap to the same amount as the memory effectively turns swap space off), causing it to crash with "MySQL init process failed." after a while. This is a useful test, since sloppy.io containers get no swap space either.
When a container fails due to memory limits, the fix usually is to increase the limit. Go to setting for your app, click on the "Performance" tab and change the slider to a higher value. You first may need to update your subscription to increase the amount of memory.
When debugging failing containers, there are some steps that are always a good idea to try:
Make sure the container runs locally, as described above
Check if there's a failure message when launching the container
Check logs (under Analytics)
Other common causes
If there's a typo in the image name, the image can't be pulled from its registry and the container won't start. Check the image name!
If the image is in a private repository, but you haven't set your registry credentials, it will look like the image doesn't exist. Check that the registry credentials are set!
Some containers (ubuntu, node, busybox) won't do anything useful unless a command is provided, starting a foreground service. Check if your image requires a command!
Though an invalid command will cause the container to crash instantly (sometimes without logging anything useful). Check the command!
Often containers connect to databases and crash or get stuck if the database connection can't be established. For example, WordPress uses several environment variables like WORDPRESS_DB_HOST. Check that the container is configured properly!
Tags: troubleshooting, crash, stuck, hangs, killed, pending