Je me demande si je peux résoudre ce problème en vidant le cache Redis ou en le mettant à jour ; il n’a pas vraiment été touché depuis plus de 8 mois. Je n’ai jamais travaillé avec Redis personnellement, mais notre instance Discourse Tests-Pass a été configurée à l’aide de local_discourse plutôt que du Discourse Docker qui est désormais recommandé sur ce forum. Les problèmes que je rencontre sont liés au fait que les e-mails ne sont pas envoyés aux utilisateurs. Toute aide ou suggestion est la bienvenue !
Sidekiq n’est pas en cours d’exécution. De nombreuses tâches, comme l’envoi d’e-mails, sont exécutées de manière asynchrone par Sidekiq. Veuillez vous assurer qu’au moins un processus Sidekiq est en cours d’exécution.
L’essai de battement de cœur de Sidekiq a échoué, redémarrage en cours
Est-ce que cela aiderait si j’utilisais le lanceur pour reconstruire ou redémarrer le conteneur Redis ?
Usage: launcher COMMAND CONFIG [–skip-prereqs] [–docker-args STRING]
Commands:
start: Démarrer/initialiser un conteneur
stop: Arrêter un conteneur en cours d’exécution
restart: Redémarrer un conteneur
destroy: Arrêter et supprimer un conteneur
enter: Ouvrir un shell pour exécuter des commandes à l’intérieur du conteneur
logs: Afficher les journaux Docker d’un conteneur
bootstrap: Initialiser un conteneur pour la configuration basée sur un modèle
run: Exécuter la commande donnée avec la configuration dans le contexte de la dernière image initialisée
rebuild: Reconstruire un conteneur (détruire l’ancien, initialiser, démarrer le nouveau)
cleanup: Supprimer tous les conteneurs arrêtés depuis plus de 24 heures
start-cmd: Générer la commande Docker utilisée pour démarrer le conteneur
Options:
–skip-prereqs Ne pas vérifier les prérequis du lanceur
–docker-args Arguments supplémentaires à passer lors de l’exécution de Docker
–skip-mac-address Ne pas attribuer d’adresse MAC
–run-image Remplacer l’image utilisée pour exécuter le conteneur
Avez-vous installé en suivant le guide Installation standard officielle de Discourse ou d’une autre manière ? Si vous avez une installation standard, alors oui, exécuter ./launcher rebuild app résoudra probablement votre problème.
Pas encore, mais nous sommes en train de fixer une date pour la migration. Notre instance Discourse tourne depuis presque trois ans et je ne veux simplement pas ajouter de temps d’arrêt inutile. Notre instance est entièrement gérée par des bénévoles, alors j’ai appris à la maintenir moi-même au cours du dernier mois. Si une correction rapide de Redis peut aider (ce conteneur tourne depuis un an sans être touché), je souhaiterais l’appliquer.
Si vous n’avez pas effectué une installation standard au départ, il est impossible de savoir ce qui pourrait résoudre votre problème actuel.
Je vous recommande de configurer une nouvelle machine virtuelle (VM) et d’y effectuer une installation de test pour vous assurer que tout fonctionne. Lors du transfert, vous pouvez mettre l’ancien forum en mode lecture seule, effectuer une sauvegarde, la restaurer sur la nouvelle VM, puis modifier les enregistrements DNS avec un temps d’arrêt quasi nul. (Il y aura en réalité un léger délai, car vous devrez reconstruire après la modification des DNS pour installer un certificat Let’s Encrypt.)
Merci, Let’s Encrypt devrait en fait être assez simple à mettre en place, car il s’agit d’une simple modification du proxy inverse nginx. C’est bon à savoir, et il faut s’attendre à une certaine interruption de service. Il suffit de programmer cela pendant une heure creuse.
Je suis sur le point de migrer et de restaurer la sauvegarde dans les images officielles. Y a-t-il des points importants à connaître concernant la suppression des e-mails sauvegardés, etc., qui pourraient spammer les utilisateurs une fois Sidekiq, etc., correctement opérationnel ? Merci !
La file d’attente des tâches Sidekiq ne bougera pas, ce qui entraînera la perte de nombreux e-mails, tandis que les résumés reprendront leur envoi normalement.
Donc, en essayant de suivre la documentation pour l’installation des images Docker officielles de Discourse, nous rencontrons des problèmes. Nous avons conclu qu’il nous manque les conteneurs Redis, mail-receiver et data que nous avions précédemment sous Docker.
Il semble que notre installation précédente comprenne : app.yml data.yml mail-receiver.yml redis.yml
Cette configuration multi-conteneurs diffère des instructions d’installation de base. J’ai bien une sauvegarde de notre ancien /var/discourse pour référence.
ÉCHEC │················································································································
-------------------- │················································································································
Pups::ExecError : cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' a échoué avec le code de retour #<Process::Status: pid 645 exit 1> │················································································································
Emplacement de l'échec : /pups/lib/pups/exec_command.rb:112:in `spawn' │················································································································
Exécution échouée avec les paramètres {"cd"=>"$home", "hook"=>"db_migrate", "cmd"=>["su discourse -c 'bundle exec rake db:migrate'"]} │················································································································
bbf0e57ac69f1febe2a5f149aa7e6e12541c3c23aaf199188fdf19d507254b58 │················································································································
** ÉCHEC DU BOOTSTRAP ** Veuillez faire défiler vers le haut et rechercher les messages d'erreur précédents, il peut y en avoir plus d'un. │················································································································
./discourse-doctor peut aider à diagnostiquer le problème.
Il semble que nous ayons manqué l’étape ./launcher bootstrap data ./launcher start redis
[Mon 11 May 2020 12:53:20 AM UTC] Exécution de la commande de rechargement : sv reload nginx │················································································································
échec : nginx : runsv n'est pas en cours d'exécution │················································································································
[Mon 11 May 2020 12:53:20 AM UTC] Erreur de rechargement pour : │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Les domaines n'ont pas été modifiés. │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Ignoré, prochaine date de renouvellement : Thu 09 Jul 2020 11:33:04 PM UTC │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Ajoutez '--force' pour forcer le renouvellement. │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Installation de la clé vers :/shared/ssl/discuss.noisebridge.info_ecc.key │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Installation de la chaîne complète vers :/shared/ssl/discuss.noisebridge.info_ecc.cer │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Exécution de la commande de rechargement : sv reload nginx │················································································································
échec : nginx : runsv n'est pas en cours d'exécution │················································································································
[Mon 11 May 2020 12:53:21 AM UTC] Erreur de rechargement pour : │················································································································
run-parts : exécution de /etc/runit/1.d/remove-old-socket │················································································································
Démarrage de runsvdir, PID est 626 │················································································································
ok : run : redis : (pid 636) 0s │················································································································
chgrp : groupe invalide : 'syslog' │················································································································
ok : run : postgres : (pid 639) 0s │················································································································
rsyslogd : imklog : impossible d'ouvrir le journal du noyau (/proc/kmsg) : Opération non autorisée. │················································································································
rsyslogd : échec de l'activation du module imklog [v8.1901.0 voir https://www.rsyslog.com/e/2145 ] │················································································································
PID du superviseur : 640, PID d'unicorn : 667
C’est exact, les importateurs ont configuré cela pour éviter que vous n’envoyiez 50 000 e-mails après une migration. Activez l’envoi d’e-mails avec précaution dans les paramètres de votre site.
Notre instance est entièrement gérée par des bénévoles, alors j’ai appris à la maintenir moi-même au cours du dernier mois. Si une correction rapide de Redis peut aider (ce conteneur tourne depuis un an sans être touché), je souhaiterais l’appliquer.