8.3.0 docker image fails to start

[Dup4]

Description of the problem

Replace this line with a short description.

docker run \
    -d \
    --restart=always \
    --name="${NAME}" \
    -e CONTAINER_TIMEZONE="${TZ}" \
    -e WEBAPP_BASEURL=/domjudge \
    -e MYSQL_HOST="${MYSQL_HOST}" \
    -e MYSQL_PORT="${MYSQL_PORT}" \
    -e MYSQL_DATABASE="${MYSQL_DATABASE}" \
    -e MYSQL_USER="${MYSQL_USER}" \
    -e MYSQL_PASSWORD="${MYSQL_PASSWORD}" \
    -e MYSQL_ROOT_PASSWORD="${MYSQL_PASSWORD}" \
    -p "${DOMSERVER_PORT}":80 \
    "domjudge/domserver:8.3.0"

Use this command to start the image

It's failing to start.

And I checked, and there are no target file in the corresponding directory.

https://github.com/DOMjudge/domjudge-packaging/blob/main/docker/domserver/scripts/start.d/50domjudge.sh#L227

I'm guessing the crash was here at startup.

And I'm guessing that the reason for this is that the symfony/runtime was not included in the build image.

Your environment

Include details about your installation here.

• DOMjudge version (e.g. 7.0.0 or a github commit hash)
• Operating system / Linux distribution and version (e.g. Ubuntu 18.04)
• Webserver (e.g. Apache or nginx)

• DOMjudge: 8.3.0
• OS: Ubuntu 22.04

[vmcj]

We are aware of the issue indeed, I already pushed to the latest tag back for the earlier image (which is why you encounter this only when you explicit pick that container). I've now also removed the tag 8.3.0 itself to prevent the problem even further.

I hope to have time to fix the container this week but feel free to create a PR to fix it.

[Dup4]

Okay, I'll workaround with the latest version first.

[Dup4]

https://github.com/composer/composer/issues/11839

This maybe the reason

[Dup4]

https://github.com/Dup4/domjudge-packaging/blob/main/docker/domserver/Dockerfile#L5

After adding this environment variable and rebuilding the image, I was able to get 8.3.0 up and running!

[vmcj]

https://github.com/Dup4/domjudge-packaging/blob/main/docker/domserver/Dockerfile#L5

After adding this environment variable and rebuilding the image, I was able to get 8.3.0 up and running!

Yes, but that's not the fix I want in the end (do still PR it though). I prefer we would have detected this in our CI before and would have fixed that composer never runs as root.

[tom93]

Hi, I'd like to help fix this, either using the workaround (COMPOSER_ALLOW_SUPERUSER=1) or properly.

@vmcj, I see you've made some changes but it's still not working for me using commit DOMjudge/domjudge@ab267ec1bd81.

One of the commit messages says "We now track the autoload_runtime file" but I don't see it in Git, is that intentional?

I tried to move the dump-autoload invocation into the composer-dependencies(-dev) targets in webapp/Makefile and that seems to work (my reasoning was that it needs to run before the install-domserver target to avoid running as root). Does that sound like a proper solution?

@nickygerritsen, do you remember why you originally ran dump-autoload using a prerequisite of install-domserver (commit DOMjudge/domjudge@508adc58e5e) as opposed to e.g. as part of the composer-dependencies target?

By the way, if I remove the --no-plugins option from the composer install commands then it works even without dump-autoload. I don't know if that helps. The --no-plugins option was was added in commit DOMjudge/domjudge@ec3bbcd531ad.

---

I'll include the error message below as text for searchability:

PHP Fatal error: Uncaught LogicException: Symfony Runtime is missing. Try running "composer require symfony/runtime". in /opt/domjudge/domserver/webapp/bin/console:8

[vmcj]

Hi, I'd like to help fix this, either using the workaround (COMPOSER_ALLOW_SUPERUSER=1) or properly.

This should be fixed properly, so not with the COMPOSER_ALLOW_SUPERUSER.

@vmcj, I see you've made some changes but it's still not working for me using commit DOMjudge/domjudge@ab267ec1bd81.

I have a holiday next week and was planning to look into it that week.

One of the commit messages says "We now track the autoload_runtime file" but I don't see it in Git, is that intentional?

Track as in the Makefile tracks if the file exists, not tracking in git.

I tried to move the dump-autoload invocation into the composer-dependencies(-dev) targets in webapp/Makefile and that seems to work (my reasoning was that it needs to run before the install-domserver target to avoid running as root). Does that sound like a proper solution?

I think this is what I already did (and it worked at that point) but my refactor to change the lib/vendor to webapp is properly the mistake.

[tom93]

my refactor to change the lib/vendor to webapp is properly the mistake.

You're right, it works on the previous commit.

[vmcj]

my refactor to change the lib/vendor to webapp is properly the mistake.

You're right, it works on the previous commit.

Currently trying to fix it with https://github.com/DOMjudge/domjudge/pull/2618

[vmcj]

This is fixed with 8.3.1.