Erro no Redis após atualização

Olá,

Após atualizar via a interface web, não consigo mais acessar meu site. Não alterei nada, apenas cliquei no botão de atualização! Os erros sugerem problemas de conexão com o Redis. Pesquisei bastante, mas ainda não encontrei nada que ajude. O production.log está vazio. Está rodando Ubuntu no Digital Ocean. Funcionou perfeitamente por 18 meses, sem erros, exceto quando acabei com o espaço em disco há 6 meses, situação que resolvi aumentando o espaço.

O espaço em disco está ok :-

Filesystem      Size  Used Avail Use% Mounted on
overlay          49G   25G   24G  52% /
tmpfs            64M     0   64M   0% /dev
tmpfs          1001M     0 1001M   0% /sys/fs/cgroup
shm             512M  8.0K  512M   1% /dev/shm
/dev/vda1        49G   25G   24G  52% /shared
tmpfs          1001M     0 1001M   0% /proc/acpi
tmpfs          1001M     0 1001M   0% /proc/scsi
tmpfs          1001M     0 1001M   0% /sys/firmware

O unicorn.stdout.log mostra:

> 2020-06-03T06:29:28.352Z pid=715 tid=osk2fuo0n ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
> 2020-06-03T06:29:28.353Z pid=715 tid=osk2fszrb ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
> 2020-06-03T06:29:28.354Z pid=715 tid=osk2fsjw3 ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
> 2020-06-03T06:29:28.354Z pid=715 tid=osk2ftlhz ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
> 2020-06-03T06:29:28.355Z pid=715 tid=osk2ftr43 ERROR: Error fetching job: Error connecting to Redis on localhost:6379 (Errno::EADDRNOTAVAIL)
> Starting up 1 supervised sidekiqs
> Loading Sidekiq in process id 725

Primeiro, tentei reconstruir o aplicativo manualmente.

Depois, tentei apt upgrade docker, reiniciei o servidor usando reboot e reconstruí usando ./launcher rebuild app.

O comando redis-cli ping retorna uma resposta PONG.

ss -t
State      Recv-Q Send-Q Local Address:Port                 Peer Address:Port   
ESTAB      0      0      104.248.166.162:ssh                  5.81.114.19:56270 
ESTAB      0      0      104.248.166.162:ssh                  5.81.114.19:56211 

O ps -axf mostra que está em execução:

  PID TTY      STAT   TIME COMMAND
 2378 pts/1    Ss     0:00 /bin/bash --login
 2849 pts/1    R+     0:00  \_ ps -axf
    1 pts/0    Ss+    0:00 /bin/bash /sbin/boot
  627 pts/0    S+     0:00 /usr/bin/runsvdir -P /etc/service
  628 ?        Ss     0:00  \_ runsv rsyslog
  641 ?        Sl     0:00  |   \_ rsyslogd -n
  629 ?        Ss     0:00  \_ runsv cron
  640 ?        S      0:00  |   \_ cron -f
  630 ?        Ss     0:00  \_ runsv unicorn
  639 ?        S      0:00  |   \_ /bin/bash config/unicorn_launcher -E producti
  665 ?        Sl     0:09  |       \_ unicorn master -E production -c config/un
  725 ?        SNl    0:12  |       |   \_ sidekiq 6.0.7 discourse [0 of 5 busy]
  750 ?        Sl     0:20  |       |   \_ unicorn worker[0] -E production -c co
  758 ?        Sl     0:17  |       |   \_ unicorn worker[1] -E production -c co
 2848 ?        S      0:00  |       \_ sleep 1
  631 ?        Ss     0:00  \_ runsv postgres
  635 ?        S      0:00  |   \_ svlogd /var/log/postgres
  636 ?        S      0:00  |   \_ /usr/lib/postgresql/12/bin/postmaster -D /etc
  659 ?        Ss     0:00  |       \_ postgres: 12/main: checkpointer
  660 ?        Ss     0:00  |       \_ postgres: 12/main: background writer
  661 ?        Ss     0:00  |       \_ postgres: 12/main: walwriter
  662 ?        Ss     0:00  |       \_ postgres: 12/main: autovacuum launcher
  663 ?        Ss     0:00  |       \_ postgres: 12/main: stats collector
  664 ?        Ss     0:00  |       \_ postgres: 12/main: logical replication la
  691 ?        Ss     0:00  |       \_ postgres: 12/main: discourse discourse [l
 1848 ?        Ss     0:00  |       \_ postgres: 12/main: discourse discourse [l
 2633 ?        Ss     0:00  |       \_ postgres: 12/main: discourse discourse [l
 2675 ?        Ss     0:00  |       \_ postgres: 12/main: discourse discourse [l
 2840 ?        Ss     0:00  |       \_ postgres: 12/main: discourse discourse [l
  632 ?        Ss     0:00  \_ runsv nginx
  634 ?        S      0:00  |   \_ nginx: master process /usr/sbin/nginx
  654 ?        S      0:02  |       \_ nginx: worker process
  655 ?        S      0:00  |       \_ nginx: cache manager process
  633 ?        Ss     0:00  \_ runsv redis
  637 ?        S      0:00      \_ svlogd /var/log/redis
  638 ?        Sl     0:05      \_ /usr/bin/redis-server *:6379

Alguma ideia? Não sou especialista e estou com muita dificuldade para encontrar uma solução para fazer isso voltar a funcionar. Será que estou ignorando algo simples? Há algum outro lugar que eu possa verificar que possa me ajudar a identificar o problema?

Obrigado

Ah… vejo que você reiniciou e fez todas as coisas óbvias…

Pode colar sua configuração do container (sem senhas)? O template do Redis está misturado?

Há algo de interessante nos docker logs app?

O localhost está sendo resolvido dentro do seu container?

Oi, Sam, desculpe minha falta de conhecimento,

você está se referindo ao arquivo app.yml?

quais são os logs do Docker? Eu executei ./launcher logs app

run-parts: executando /etc/runit/1.d/00-ensure-links
run-parts: executando /etc/runit/1.d/00-fix-var-logs
run-parts: executando /etc/runit/1.d/anacron
run-parts: executando /etc/runit/1.d/cleanup-pids
Limpando arquivos PID obsoletos
run-parts: executando /etc/runit/1.d/copy-env
run-parts: executando /etc/runit/1.d/letsencrypt
[Qua 03 Jun 2020 06:34:47 UTC] Domínios não alterados.
[Qua 03 Jun 2020 06:34:47 UTC] Ignorando, próximo horário de renovação: Qua Jul  1 00:35:12 UTC 2020
[Qua 03 Jun 2020 06:34:47 UTC] Adicione '--force' para forçar a renovação.
[Qua 03 Jun 2020 06:34:47 UTC] Instalando chave em: /shared/ssl/forum.tritalk.co.uk.key
[Qua 03 Jun 2020 06:34:47 UTC] Instalando cadeia completa em: /shared/ssl/forum.tritalk.co.uk.cer
[Qua 03 Jun 2020 06:34:47 UTC] Executando comando de recarga: sv reload nginx
aviso: nginx: não foi possível abrir supervise/ok: arquivo inexistente
[Qua 03 Jun 2020 06:34:47 UTC] Erro de recarga para :
[Qua 03 Jun 2020 06:34:48 UTC] Domínios não alterados.
[Qua 03 Jun 2020 06:34:48 UTC] Ignorando, próximo horário de renovação: Qui Jul  9 00:35:12 UTC 2020
[Qua 03 Jun 2020 06:34:48 UTC] Adicione '--force' para forçar a renovação.
[Qua 03 Jun 2020 06:34:48 UTC] Instalando chave em: /shared/ssl/forum.tritalk.co.uk_ecc.key
[Qua 03 Jun 2020 06:34:48 UTC] Instalando cadeia completa em: /shared/ssl/forum.tritalk.co.uk_ecc.cer
[Qua 03 Jun 2020 06:34:48 UTC] Executando comando de recarga: sv reload nginx
aviso: nginx: não foi possível abrir supervise/ok: arquivo inexistente
[Qua 03 Jun 2020 06:34:48 UTC] Erro de recarga para :
runsvdir iniciado, PID é 627
ok: run: redis: (pid 638) 0s
ok: run: postgres: (pid 636) 0s
chgrp: grupo inválido: 'syslog'
rsyslogd: imklog: não foi possível abrir o log do kernel (/proc/kmsg): Operação não permitida.
rsyslogd: falha na ativação do módulo imklog [v8.1901.0 tente https://www.rsyslog.com/e/2145 ]
pid do supervisor: 639 pid do unicorn: 665

Dentro do contêiner, tentei o comando, não tenho certeza se era isso que você quis dizer

tritalk@TriTalk-Discourse:/var/discourse$ sudo ./launcher enter app
root@TriTalk-Discourse-app:/var/www/discourse# curl http://localhost:8080
curl: (7) Falha ao conectar em localhost porta 8080: Conexão recusada

Sim, app.yml, mas por favor remova qualquer senha ou informação sensível.

## este é o modelo de contêiner Docker Discourse standalone, tudo-em-um
##
## Após fazer alterações neste arquivo, você DEVE reconstruir
## /var/discourse/launcher rebuild app
##
## TENHA MUITO, MUITO CUIDADO AO EDITAR!
## ARQUIVOS YAML SÃO SUPER, SUPER SENSÍVEIS A ERROS EM ESPAÇOS EM BRANCO OU ALINHAMENTO!
## visite http://www.yamllint.com/ para validar este arquivo conforme necessário

templates:
  - "templates/postgres.template.yml"
  - "templates/redis.template.yml"
  - "templates/web.template.yml"
  - "templates/web.ratelimited.template.yml"
## Descomente estas duas linhas se desejar adicionar o Lets Encrypt (https)
  - "templates/web.ssl.template.yml"
  - "templates/web.letsencrypt.ssl.template.yml"

## quais portas TCP/IP este contêiner deve expor?
## Se você quiser que o Discourse compartilhe uma porta com outro servidor web como Apache ou nginx,
## consulte https://meta.discourse.org/t/17247 para detalhes
expose:
  - "80:80"   # http
  - "443:443" # https

params:
  db_default_text_search_config: "pg_catalog.english"

  ## Defina db_shared_buffers para no máximo 25% da memória total.
  ## será definido automaticamente pelo bootstrap com base na RAM detectada, ou você pode substituir
  db_shared_buffers: "128MB"

  ## pode melhorar o desempenho de ordenação, mas aumenta o uso de memória por conexão
  #db_work_mem: "40MB"

  ## Qual revisão do Git este contêiner deve usar? (padrão: tests-passed)
  #version: tests-passed

env:
  LANG: en_US.UTF-8
  # DISCOURSE_DEFAULT_LOCALE: en

  ## Quantas solicitações web simultâneas são suportadas? Depende de memória e núcleos de CPU.
  ## será definido automaticamente pelo bootstrap com base nas CPUs detectadas, ou você pode substituir
  UNICORN_WORKERS: 2

  ## TODO: O nome de domínio ao qual esta instância do Discourse responderá
  ## Obrigatório. O Discourse não funcionará com um número IP puro.
  DISCOURSE_HOSTNAME: forum.xxxx.co.uk

  ## Descomente se quiser que o contêiner seja iniciado com o mesmo
  ## nome de host (opção -h) especificado acima (padrão "$hostname-$config")
  #DOCKER_USE_HOSTNAME: true

  ## TODO: Lista de e-mails separados por vírgula que serão definidos como administradores e desenvolvedores
  ## no cadastro inicial, exemplo 'user1@example.com,user2@example.com'
  DISCOURSE_DEVELOPER_EMAILS: 'admin@xxxx.co.uk'

  ## TODO: O servidor de correio SMTP usado para validar novas contas e enviar notificações
  # ENDEREÇO SMTP, nome de usuário e senha são obrigatórios
  # AVISO: o caractere '#' na senha SMTP pode causar problemas!
  DISCOURSE_SMTP_ADDRESS: in-v3.mailjet.com
  DISCOURSE_SMTP_PORT: 587
  DISCOURSE_SMTP_USER_NAME: xxxx
  DISCOURSE_SMTP_PASSWORD: "xxxx"
  #DISCOURSE_SMTP_ENABLE_START_TLS: true           # (opcional, padrão true)

  ## Se você adicionou o modelo Lets Encrypt, descomente abaixo para obter um certificado SSL gratuito
  LETSENCRYPT_ACCOUNT_EMAIL: admin@xxxx.co.uk

  ## O endereço CDN para esta instância do Discourse (configurado para buscar)
  ## consulte https://meta.discourse.org/t/14857 para detalhes
  #DISCOURSE_CDN_URL: //discourse-cdn.example.com

## O contêiner Docker é sem estado; todos os dados são armazenados em /shared
volumes:
  - volume:
      host: /var/discourse/shared/standalone
      guest: /shared
  - volume:
      host: /var/discourse/shared/standalone/log/var-log
      guest: /var/log

## Plugins vão aqui
## consulte https://meta.discourse.org/t/19157 para detalhes
hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - mkdir -p plugins
          - git clone https://github.com/discourse/discourse-adplugin.git
          - git clone https://github.com/discourse/discourse-affiliate.git

## Quaisquer comandos personalizados para executar após a construção
run:
  - exec: echo "Início dos comandos personalizados"
  ## Se quiser definir o endereço de e-mail 'De' para seu primeiro cadastro, descomente e altere:
  ## Após receber o primeiro e-mail de cadastro, comente novamente a linha. Só precisa ser executado uma vez.
  - exec: rails r "SiteSetting.notification_email='admin@xxxx.co.uk'"
  - exec: echo "Fim dos comandos personalizados"

Isso é um problema. Qual versão do Docker você está executando? O que o comando docker info retorna?

Você não está errado! É como se o banco de dados não pudesse ser encontrado; quando você acessa o site, aparece apenas uma tela com títulos.

Informações do Docker:

Cliente:
 Modo de depuração: falso

Servidor:
 Contêineres: 2
  Em execução: 1
  Pausados: 0
  Parados: 1
 Imagens: 6
 Versão do servidor: 19.03.11
 Driver de armazenamento: overlay2
  Sistema de arquivos de suporte: extfs
  Suporta d_type: verdadeiro
  Diferença nativa de overlay: verdadeiro
 Driver de log: json-file
 Driver de cgroup: cgroupfs
 Plugins:
  Volume: local
  Rede: bridge host ipvlan macvlan null overlay
  Log: awslogs fluentd gcplogs gelf journald json-file local logentries splunk syslog
 Swarm: inativo
 Runtimes: runc
 Runtime padrão: runc
 Binário de inicialização: docker-init
 Versão do containerd: 7ad184331fa3e55e52b890ea95e65ba581ae3429
 Versão do runc: dc9208a3303feef5b3839f4323d9beb36df0a9dd
 Versão de inicialização: fec3683
 Opções de segurança:
  apparmor
  seccomp
   Perfil: padrão
 Versão do kernel: 4.4.0-179-generic
 Sistema operacional: Ubuntu 16.04.6 LTS
 OSType: linux
 Arquitetura: x86_64
 CPUs: 1
 Memória total: 1.953GiB
 Nome: TriTalk-Discourse
 ID: SYIS:XPWU:W2SP:NYNA:GFP7:DNVK:E7JF:553N:EGWF:OR7M:TV2E:A6ZX
 Diretório raiz do Docker: /var/lib/docker
 Modo de depuração: falso
 Registro: https://index.docker.io/v1/
 Etiquetas:
 Experimental: falso
 Registros inseguros:
  127.0.0.0/8
 Restauração ao vivo ativada: falso

AVISO: Sem suporte para limite de swap

Você pode tentar o modo de segurança?

Usei o modo de segurança e, se eu entrar sem desativar os plugins, falha. Então parece que um dos plugins está com problemas desde a atualização. Comentei-os no arquivo yml, recriei o aplicativo e tudo funcionou. É ou o discourse-affiliate ou o discourse-adplugin. Investigarei mais a fundo mais tarde, mas pelo menos o site está no ar e funcionando novamente. Obrigado por toda a ajuda. Nota para mim mesmo: use o modo de segurança para fazer verificações preliminares no futuro!

Sua área de plugins não parece estar formatada corretamente. Talvez isso esteja causando o problema?

Na verdade, deveria parecer com:

        cmd:
          - git clone https://github.com/discourse/docker_manager.git
          - git clone https://github.com/discourse/discourse-adplugin.git
          - git clone https://github.com/discourse/discourse-affiliate.git

(retire o -mkdir -p plugins)
Esperamos que isso resolva o problema com os plugins.

Obrigado, Bhanu. Vou tentar. É estranho que tenha funcionado até hoje. Talvez algo tenha sido reforçado na versão mais recente do Docker.

Posso estar enganado aqui. Nunca usei esse parâmetro nos meus arquivos yml e até agora funciona perfeitamente.

Olá @carlb,

FYI, o Redis é usado principalmente para jobs em segundo plano (junto com seu companheiro agendador de jobs, o Sidekiq); e, FWIW, quando estou no ambiente de desenvolvimento, costumo executar o Discourse sem o Redis ou o Sidekiq em execução, pois não quero que esses “jobs em segundo plano” rodem.

Portanto, seu fórum Discourse ainda deve exibir os fóruns principais, os tópicos, os usuários, as publicações, etc., mesmo que o Redis não esteja em execução. Só respondo com esse FWIW porque você intitulou seu tópico:

Erro do Redis após atualização

… e então, gentilmente, forneceu uma captura de tela do seu fórum com vários problemas básicos que não estão diretamente relacionados ao Redis em si.

Obrigado pela explicação. Não tenho muito conhecimento sobre como tudo isso se encaixa, já que tudo sempre funciona e eu nunca precisei me aprofundar, então isso me ajuda no futuro. Eu apenas assumi que, como todos os erros que encontrei mencionam falha na conexão com o Redis, isso pode ser a causa raiz. Nenhuma das soluções habituais que normalmente resolvem problemas básicos funcionou.