Upgrading 6.2 to 6.3

Technical assistance
1

Infos:

  • Used Zammad version: 6.2
  • Used Zammad installation type: docker-compose
  • Operating system: Ubuntu 20

Expected behavior:

  • Ran the docker-compose pull - OK
  • Ran the docker-compose up
  • Expected everything to start OK.

Actual behavior:

zammad-scheduler_1      | waiting for init container to finish install or update...
zammad-websocket_1      | waiting for init container to finish install or update...
zammad-nginx_1          | waiting for init container to finish install or update...

Steps to reproduce the behavior:

  • I am simply trying to move from the docker-compose v11.2.0 release to v11.3.0.
  • There does not appear to be any errors in the output messages, but it seems the init task is existing with code 0.

zammad-docker-compose_zammad-init_1 exited with code 0

Appreciate any advise if someone was able to get past this part. Upgrading minor version seems pretty fragile.
Here are the last few messages from zammad-init…

zammad-init_1           | I, [2024-11-21T20:49:27.466077 #61]  INFO -- : ActionCable is using the redis instance at redis://zammad-redis:6379.
zammad-init_1           | I, [2024-11-21T20:49:27.485871#61-6060]  INFO -- : Using memcached as Rails cache store.
zammad-init_1           | I, [2024-11-21T20:49:27.486687#61-6060]  INFO -- : Using the Redis back end for Zammad's web socket session store.
zammad-scheduler_1      | waiting for init container to finish install or update...
zammad-init_1           | I, [2024-11-21T20:49:30.015910#61-6060]  INFO -- : Setting.set('es_index', "zammad")
zammad-docker-compose_zammad-init_1 exited with code 0
2

Hi vanboom,

the init-container has to exit after a while. When you start up zammad the init
container is used to bring up all the components to a running state. Zammad
is ready to run when the init container has stopped.

Normal behavior.

sunny greetings
byPARSE

3

We have been experiencing the same issue for some time now. I believe I had to basically nuke the ES data and that somehow fixes the problem for a little bit.

4

@AddoSolutions seems to match what we are seeing. The other containers would hang waiting for the init container to complete, but it had already exited.

Deleting the ES data resolved it. Thanks!