Uso o Discourse há vários anos. Configuro uma nova instância a cada 6 meses. Minha configuração inclui Docker e um proxy baseado em Nginx, então talvez seja um pouco não padrão. Por esse motivo, não estou usando o discourse-setup.
A cada 6 meses, quando repito esse processo, depois de clonar uma cópia limpa do Discourse de seu git e executar ./launcher bootstrap app, o contêiner falha ao iniciar. O log mostra:
anacron: Can't chdir to /var/spool/anacron: No such file or directory
run-parts: /etc/runit/1.d/anacron exited with return code 1
run-parts: executing /etc/runit/1.d/00-ensure-links
run-parts: executing /etc/runit/1.d/00-fix-var-logs
run-parts: executing /etc/runit/1.d/01-cleanup-web-pids
run-parts: executing /etc/runit/1.d/anacron
anacron: Can't chdir to /var/spool/anacron: No such file or directory
ad infinitum.
Geralmente, faço uma série de etapas para reconfigurar, reiniciar, remover plugins, adicioná-los novamente, etc., até que finalmente funcione, sem nunca aprender o que realmente fez funcionar. 6 meses depois, a mesma coisa acontece novamente. Eu trabalho apenas para consertar, e não está claro qual das muitas etapas que tomo na época realmente fez funcionar.
Desta vez, porém, acredito que finalmente encontrei o problema, e é este: aparentemente, ./launcher start app reinicia instâncias de contêiner antigas chamadas app, mesmo quando o Discourse foi clonado e reconfigurado.
A etapa que falta é docker remove app. Em resumo:
./launcher stop app
docker remove app
... agora clonar, reconfigurar e launcher start app funciona
Meu erro foi esperar que, após executar ./launcher bootstrap app, o próximo ./launcher start app iniciasse a nova imagem do contêiner, mas isso não parece ser o caso. Naturalmente, as coisas dão errado com a antiga, já que o caminho /var/discourse/shared foi reinicializado.
Estou deixando isso aqui caso outros procurem pelas mesmas mensagens de erro de log.
Como uma possível melhoria, seria bom se o contêiner detectasse que seu diretório /var/discourse/shared mudou.