Bug: changing an app's Redis memory limit does not restart the container, so maxmemory stays at the old value

[imc67]

On 9.2.x, changing the Redis memory limit for an app under Services updates the container's cgroup limit right away, but does not restart the Redis container. maxmemory is written when the container starts, so redis keeps running with the value from its previous start.

That is harmless when you raise the limit. It is not when you lower it. Two days after lowering one app's Redis from 512 MB to 256 MB:

docker inspect -f '{{.HostConfig.Memory}}' redis-<appid>
268435456

redis-cli config get maxmemory
526385152

With maxmemory-policy noeviction, redis will grow to 502 MB before it starts refusing writes, while the cgroup kills it at 256 MB. So instead of an "OOM command not allowed" error you get a killed container.

What made this hard to notice: the very first time you configure an app's Redis, the service does get rebuilt. Only the changes after that don't. A single test therefore looks like it works. Restarting the service by hand afterwards puts maxmemory right again.

Would it make sense to restart the service container on a memory limit change, the same way the app container is now rebuilt when its memory limit changes?

[girish]

Right, this is already fixed now along with the mysql changes . When services are resized, they are now restarted since start.sh is making decisions based on the allocated memory - https://git.cloudron.io/platform/box/-/commit/9b0f8aea0dbf5788d653392ca83874d0aa803503