WeblateOrg / docker

Official Docker container for Weblate, a libre software web-based continuous localization system
https://docs.weblate.org/en/latest/admin/install/docker.html
GNU General Public License v3.0
89 stars 106 forks source link

Container fails to start because of existing symlink #2579

Closed raymondelooff closed 2 weeks ago

raymondelooff commented 3 weeks ago

Describe the issue

Because of changes in c5a1c3b, containers now fail to start a second time after being stopped. The start script tries to create Supervisor config file symlinks, but those ln -s commands fail when a symlink already exists (because they get created during the first start). Adding the -f flag to all the symlink commands will likely fix the issue.

weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/celery-backup.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/celery-beat.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/celery-celery.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/celery-memory.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/celery-notify.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/celery-translate.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/check.conf': File exists
weblate-1  | ln: failed to create symbolic link '/var/run/supervisor.conf.d/web.conf': File exists

I already tried

Steps to reproduce the behavior

  1. Start a new container
  2. Stop the container, don't remove it
  3. Start the container again

Expected behavior

No response

Screenshots

No response

Exception traceback

No response

Additional context

No response

nijel commented 3 weeks ago

We should also add tests to cover this situation while fixing this.

nijel commented 2 weeks ago

This doesn't happen in the recommended setup when using tmpfs for /run, as in that case, the tmpfs doesn't survive the container restart.

github-actions[bot] commented 2 weeks ago

Thank you for your report; the issue you have reported has just been fixed.