Forum non disponibile con errore Redis nei log di unicorn (

Ciao.

Sto ospitando due forum sulla mia macchina, entrambi sono aggiornati (uno è alla versione 3.4.0.beta3-dev, e non riesco a controllare l’altro che non è disponibile).

Uno di questi è stato aggiornato all’inizio di questa settimana e ha smesso improvvisamente di funzionare circa 2 giorni fa.

Una volta effettuato l’accesso, appare un messaggio “Oops” su ogni pagina.

Sono entrato nel container e ho controllato i log di unicorn e sembra esserci un problema di connessione con redis:

Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Error fetching job: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED)
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 3 Job exception: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) sidekiq-exception
Failed to report error: Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) 2 Error connecting to Redis on localhost:6379 (Errno::ECONNREFUSED) subscribe failed, reconnecting in 1 second. Call stack /var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:398:in `rescue in establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:379:in `establish_connection'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:115:in `block in connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:344:in `with_reconnect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:114:in `connect'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:409:in `ensure_connected'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:269:in `block in process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:356:in `logging'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:268:in `process'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/client.rb:161:in `call'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/rack-mini-profiler-3.3.1/lib/mini_profiler/profiling_methods.rb:89:in `block in profile_method'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:270:in `block in send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `synchronize'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis.rb:269:in `send_command'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/redis-4.8.1/lib/redis/commands/strings.rb:191:in `get'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:388:in `process_global_backlog'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:277:in `block in global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus/backends/redis.rb:289:in `global_subscribe'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:768:in `global_subscribe_thread'
/var/www/discourse/vendor/bundle/ruby/3.3.0/gems/message_bus-4.3.8/lib/message_bus.rb:739:in `block in new_subscriber_thread'

Il problema è che non capisco cosa ci sia di sbagliato, dato che riesco a connettermi al server redis nel container tramite redis-cli e a impostare e ottenere chiavi senza problemi.

Vedo molti problemi simili sul forum, ma sono vecchi o non hanno avuto alcuna risoluzione. Qualcuno può aiutarmi? Posso fornire maggiori informazioni se necessario.

1 Mi Piace

Questo funzionava?

Da quanto tempo hai iniziato?

Hai due versioni di un file app.yml standard, ognuna con il proprio template Redis e postgres e percorsi diversi per i dati?

Una possibilità sono i permessi. A un certo punto l’ID dell’utente e del gruppo utilizzati è cambiato, ma non ho mai visto che questo fosse un problema nelle configurazioni a container singolo.

Grazie per aver esaminato il mio problema.

Sì, questo funzionava fino a circa 3 giorni fa. Tuttavia, stamattina ho provato a eseguire un backup dalla CLI all’interno del container e non è riuscito a causa di uno strano errore postgres, quindi sospetto che il database sia in qualche modo corrotto. Il che non è assolutamente rilevante per il messaggio di errore che ho menzionato sopra, ma sono propenso a provare a ripristinare un backup funzionante di 8 giorni fa (il proprietario del forum è d’accordo) per vedere se risolve tutto.

Suppongo di poter ripristinare un backup da una versione precedente di Discourse a una più recente? (poiché c’è stato un aggiornamento tra il backup e ora.)

EDIT: per chiarire, i due forum sono file yaml diversi, quindi ognuno ha il proprio container con cui lavorare e directory dati ovviamente diverse.

È fallito durante il backup o il ripristino?

Sarebbe utile se includessi l’errore strano, ma se fosse stato durante il ripristino sospetto che sia quello descritto qui: Restore failing with missing chat_mention function

Se è corretto, il mio consiglio è di aspettare. Se aspettare non è un’opzione, potresti provare a vedere che il sito che ripristini abbia lo stesso commit del sito che crea il backup.

È sul backup.

pg_dump: errore: il dump del contenuto della tabella "posts" è fallito: PQgetResult() non è riuscito.
pg_dump: errore: messaggio di errore dal server: ERRORE:  impossibile aprire il file "base/16384/17044": File o directory non esistente

Ecco perché ho detto che proverò prima a ripristinare un backup per vedere se risolve il problema. :slight_smile:

Sembra proprio un problema di database.

Hai mai ripristinato un backup del filesystem? Questo sembra il tipo di cosa che accadrebbe se si facesse un backup del filesystem mentre il database era in esecuzione. È uno dei motivi per cui non consiglio i backup del filesystem.

Se vuoi ripristinare un backup di discourse, cosa che di solito consiglierei, dovresti eliminare il database, e creare e migrare un database vuoto prima di eseguire il ripristino.

Eseguo backup del filesystem ma escludo i database postgres poiché li eseguo invece. Tuttavia, potrei essermi dimenticato di escludere la cartella di discourse, dovrò verificarlo più tardi.

Le informazioni in questo thread sono ancora valide per il mio caso d’uso?

La procedura per ottenere il backup dove serve sembra inutilmente complicata.

Ok, ho trovato il colpevole, grazie per avermi indicato la giusta direzione riguardo al filesystem. Abbiamo eseguito una scansione antivirus e qualcuno ha caricato qualcosa sul forum che aveva una firma virale. Di conseguenza, ClamAV ha rimosso il file. Lo ottimizzerò meglio in modo che non metta più in quarantena i file di PostgreSQL.

Scusa per la perdita di tempo :slight_smile:

1 Mi Piace

Ottimo! Sono contento che il mio suggerimento ti sia stato d’aiuto! Non ci avrei mai pensato, ma è da molto tempo che non eseguo un software antivirus.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.