Désolé si ce n’est pas la bonne catégorie pour cela.
J’évalue Discourse et le travail VersionCheck échoue dans mon environnement.
J’ai remarqué que les travaux échoués s’accumulent dans Sidekiq et seront probablement déplacés dans la section “dead” après les 25 tentatives par défaut (conformément à https://www.rubydoc.info/gems/sidekiq/Sidekiq/JobRetry).
Je sais que je dois enquêter sur la cause de l’échec, mais le fait est le suivant : est-il judicieux de conserver ces travaux là ? N’est-il pas préférable de simplement ignorer les vérifications de version échouées et d’attendre la prochaine exécution du travail ?
À l’heure actuelle, j’ai plus de 80 travaux VersionCheck en attente de nouvelle tentative et cela me semble un gaspillage de ressources (probablement minime, mais quand même un gaspillage)…
Comment avez-vous installé ? Y a-t-il une raison de croire que vous avez des problèmes de réseau ? RAM ?
Vous avez peut-être raison, mais comme vous êtes la seule personne à signaler cela (du moins jusqu’à présent), cela n’a pas été ajouté à la liste des optimisations. Il serait logique de simplement le laisser échouer après une tentative, je pense.
Quand avez-vous effectué la dernière mise à niveau ?
Il y a eu un problème avec le travail de vérification de version il y a quelques semaines (vers fin octobre), il est maintenant résolu. Si vous effectuez la mise à niveau dans le terminal (./launcher rebuild app), cela devrait aller.
J’utilise l’installation Docker standard à l’intérieur d’une instance EC2.
Je suis dans un environnement d’entreprise, il y a donc beaucoup de pare-feu, de proxys et de scanners de sécurité entre l’instance et Internet. Dans les journaux, je vois une erreur “Job exception: Connection reset by peer - SSL_connect (Errno::ECONNRESET)”, donc probablement qu’un pare-feu refuse la requête à un moment donné… Je suis encore en train de comprendre comment Discourse effectue ces vérifications de version afin de pouvoir les reproduire manuellement et obtenir plus de détails.
Je comprends tout à fait. Par le passé, j’ai travaillé avec GitLab et j’ai vu de nombreux problèmes où des files d’attente Sidekiq pleines causaient une dégradation des performances et d’autres comportements étranges, donc chaque fois que je vois quelque chose comme ça, mes alarmes sonnent.
Oui… La mise à niveau dans le terminal ou via l’interface graphique fonctionne correctement (je l’exécute chaque semaine). Le seul problème dans ce cas est que l’écran principal de l’administrateur n’affiche pas la dernière version et indique toujours que j’utilise une version obsolète.
Discourse contactera Internet pour des tâches telles que la vérification des mises à niveau de version, la récupération des avatars des utilisateurs, le téléchargement d’images distantes vers le stockage local et le oneboxing général. Si l’instance est coupée d’Internet, il y aura effectivement quelques dysfonctionnements.
Oui ! Je le fais chaque semaine jusqu’à ce que je trouve une solution.
J’ai dû abandonner le oneboxing exactement pour cette raison. Pour l’instant, je ne peux pas autoriser un accès complet à Internet pour ce serveur. github.com/* est déjà autorisé, mais ce travail de vérification de version utilise probablement une autre URL pour cela.
Ce que je ferais, c’est simplement désactiver SiteSetting.version_checks, supprimer le plugin discourse_docker et faire des mises à jour en ligne de commande.
Mais ici, si vous pouvez ouvrir https://api.discourse.org/api, alors vous êtes probablement bon.
