Comportamento dei lavori VersionCheck falliti

Mi scusi se questa non è la categoria corretta.

Sto valutando Discourse e il processo VersionCheck Job sta fallendo nel mio ambiente.

Ho notato che i processi falliti si stanno accumulando in Sidekiq e probabilmente verranno spostati nella sezione “dead” dopo i 25 tentativi predefiniti (come da https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry).

So che devo indagare su cosa ne stia causando il fallimento, ma il punto qui è: ha senso mantenere questi processi lì? Non sarebbe meglio semplicemente scartare i controlli di versione falliti e attendere la prossima esecuzione del processo?

Al momento ho più di 80 processi VersionCheck in attesa di ritentare e a me sembra uno spreco di risorse (probabilmente poco, ma comunque uno spreco)…

Da quello che ho controllato, aggiungere sidekiq_options retry: false a app/jobs/scheduled/version_check.rb risolverebbe questo problema.

Mi sfugge qualcosa?

Come hai installato? C’è motivo di credere che tu abbia problemi di rete? RAM?

Potresti avere ragione, ma dato che sei l’unica persona a segnalarlo (almeno finora) non è entrato nella lista delle ottimizzazioni. Ha senso lasciarlo fallire dopo un tentativo, suppongo.

Quando è stata l’ultima volta che hai aggiornato?

C’è stato un problema con il job di controllo della versione qualche settimana fa (intorno a fine ottobre), ora è stato risolto. Se aggiorni nel terminale (./launcher rebuild app), dovrebbe andare bene.

1 Mi Piace

Sto usando l’installazione Docker standard all’interno di un’istanza EC2.

Mi trovo in un ambiente aziendale, quindi ci sono molti firewall, proxy e scanner di sicurezza tra l’istanza e Internet. Nei log vedo un errore “Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)”, quindi probabilmente qualche firewall sta negando la richiesta a un certo punto… Sto ancora capendo come Discourse esegue questi controlli di versione in modo da poterli riprodurre manualmente e ottenere maggiori dettagli.

Capisco perfettamente. In passato ho lavorato con GitLab e ho visto molti problemi in cui code Sidekiq piene causavano degrado delle prestazioni e altri comportamenti strani, quindi ogni volta che vedo qualcosa del genere suona l’allarme. :smile:

1 Mi Piace

Sono alla versione 2.8.0.beta9 (959923d3cf)

Sì… L’aggiornamento dal terminale o tramite GUI funziona bene (lo eseguo settimanalmente). L’unico problema in questo caso è che la schermata principale dell’amministratore non mostra la versione più recente e dice sempre che sto eseguendo una versione obsoleta.

Allora dovresti assolutamente eseguire un aggiornamento da riga di comando.

Discourse contatterà Internet per attività come il controllo degli aggiornamenti di versione, il recupero delle immagini utente, il download di immagini remote in locale e il oneboxing generale. Se l’istanza viene interrotta da Internet, ci saranno effettivamente alcuni malfunzionamenti.

1 Mi Piace

Sì! Lo faccio ogni settimana finché non trovo una soluzione.

Ho dovuto rinunciare al oneboxing proprio per questo motivo. Per ora non posso consentire l’accesso completo a Internet per questo server.
github.com/* è già consentito, ma probabilmente questo lavoro di versioncheck utilizza un altro URL per farlo.

1 Mi Piace

Quello che farei è semplicemente disattivare SiteSetting.version_checks, rimuovere il plugin discourse_docker ed eseguire gli aggiornamenti da riga di comando.

Ma, qui, se riesci ad aprire https://api.discourse.org/api, allora probabilmente sei a posto.

1 Mi Piace

Grazie per le informazioni! Ha funzionato quando ho consentito l’accesso a https://api.discourse.org/api/version_check

1 Mi Piace