Problema durante ./launcher rebuild, Redis não iniciando na segunda vez

Olá a todos.

Tive um problema ao reconstruir (atualizar) o Discourse; no log, descobri que durante a configuração, um Redis é iniciado pela primeira vez, sem problemas, mas depois de um tempo a configuração tenta iniciá-lo novamente e falha devido a “server TCP listening socket *:6379: bind: Address already in use”.

Após várias tentativas e erros, também com a ajuda do Gemini, coloquei este trecho de código dentro do app.yml:

hooks: before_db_migrate: - exec: cmd: - "pkill -9 redis-server || true" - "sleep 2" - "exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf &" - "sleep 5"

e, finalmente, a reconstrução prossegue.

Aqui está um trecho do log com minha correção, matando a instância relutante do Redis e iniciando-a novamente:


389:C 24 Feb 2026 17:07:21.756 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

389:C 24 Feb 2026 17:07:21.756 * Redis version=7.4.7, bits=64, commit=00000000, modified=1, pid=389, just started

389:C 24 Feb 2026 17:07:21.756 * Configuration loaded

389:M 24 Feb 2026 17:07:21.756 * monotonic clock: POSIX clock_gettime

389:M 24 Feb 2026 17:07:21.757 * Running mode=standalone, port=6379.

389:M 24 Feb 2026 17:07:21.757 # Warning: Could not create server TCP listening socket *:6379: bind: Address already in use

389:M 24 Feb 2026 17:07:21.757 # Failed listening on port 6379 (tcp), aborting.

I, [2026-02-24T17:07:31.750972 #1]  INFO -- : > pkill -9 redis-server || true

I, [2026-02-24T17:07:31.758767 #1]  INFO -- : > sleep 2

I, [2026-02-24T17:07:33.761955 #1]  INFO -- : > exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf &

I, [2026-02-24T17:07:33.765205 #1]  INFO -- : > sleep 5

396:C 24 Feb 2026 17:07:33.773 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo

396:C 24 Feb 2026 17:07:33.773 * Redis version=7.4.7, bits=64, commit=00000000, modified=1, pid=396, just started

396:C 24 Feb 2026 17:07:33.773 * Configuration loaded

396:M 24 Feb 2026 17:07:33.773 * monotonic clock: POSIX clock_gettime

396:M 24 Feb 2026 17:07:33.774 * Running mode=standalone, port=6379.

396:M 24 Feb 2026 17:07:33.775 * Server initialized

396:M 24 Feb 2026 17:07:33.776 * Loading RDB produced by version 7.4.7

396:M 24 Feb 2026 17:07:33.776 * RDB age 19606 seconds

396:M 24 Feb 2026 17:07:33.776 * RDB memory usage when created 4.60 Mb

396:M 24 Feb 2026 17:07:33.787 * Done loading RDB, keys loaded: 3413, keys expired: 1.

396:M 24 Feb 2026 17:07:33.788 * DB loaded from disk: 0.013 seconds

396:M 24 Feb 2026 17:07:33.788 * Ready to accept connections tcp

Minha pergunta agora é: POR QUE dois inícios do Redis? E por que o segundo encontra o primeiro ainda pendurado na porta 6379? E, novamente, por que não tentar usá-lo, se ele já está disponível?
E, por último, mas não menos importante, o que poderia ter causado esse problema? Eu sei muito bem que coloquei um curativo em uma ferida sem saber POR QUE a ferida existe, mas pelo menos está funcionando agora.

Antes que alguém me pergunte, NÃO, eu não tenho nenhum outro Redis rodando fora do Discourse (caso contrário, a primeira tentativa no início da reconstrução teria falhado), e SIM, o Discourse está rodando com muitos outros contêineres no Docker, embora nunca tenha tido esse problema até algumas atualizações atrás.

Qualquer ajuda e dica são apreciadas, e desculpe se isso já foi resolvido em outro tópico, mas pesquisei sem sucesso.