Reconstruire se bloque lors de la tentative d'arrêt du conteneur

J’ai reçu aujourd’hui le message You are running an old version of the Discourse image. Upgrades via the web UI are disabled until you run the latest image et je pense avoir cassé mon installation.

J’ai suivi les instructions, en exécutant chaque commande avec sudo, car mon hébergeur ne permet pas la création d’utilisateurs root.

cd /var/discourse
sudo git pull
sudo ./launcher rebuild app

J’ai ensuite dû réexécuter sudo git stash avant le pull en raison d’une erreur liée à des conflits.

Tout semblait se dérouler normalement (j’ai laissé cela plus d’une heure), mais ma session Terminal s’est fermée (erreur de broken pipe). Pour contourner le problème, j’ai défini ClientAliveInterval sur le serveur à 60 (cette option était commentée), j’ai redémarré et j’ai réessayé.

Lorsque le script de reconstruction s’exécute maintenant, il plante lorsqu’il tente d’arrêter le conteneur Docker.

J’ai essayé de contourner ce problème en exécutant docker kill <id> avant de lancer le script de reconstruction, mais le même plantage se produit (CPU à 100 % pendant environ 15 minutes… puis rien pendant des heures).

Lorsque je redémarre, le site se lance toujours, mais je ne peux pas le mettre à jour (le mise à jour via l’interface indique toujours que j’exécute une ancienne image Discourse).

Toute aide serait grandement appréciée.

C’est assez difficile à deviner sans voir la sortie de la compilation.

Vous pourriez essayer d’utiliser tmux (ou un outil similaire) pour maintenir la session ouverte en cas de déconnexion (vous pouvez vous reconnecter à la session avec tmux attach).

Peut-être jeter un œil à la mise à jour PostgreSQL 13 ?

Merci Jay, je pense avoir trouvé le problème.

Mon fournisseur de VPS, webdock.io (qui est excellent, soit dit en passant), ne prend pas en charge ZFS car ils l’utilisent au niveau de l’hôte ; on m’a conseillé que ZFS imbriqué n’est pas une option. Ils n’ont pas non plus recommandé overlay2 pour mon installation et m’ont suggéré de modifier launcher pour inclure le pilote de stockage vfs, qui n’est pas présent par défaut.

171‎‏‏‎ ‎‏‏‎ ‎‏‏‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎ Storage Driver: (vfs|aufs|zfs|overlay2)
‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎‎‏‏‎ ‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎‎‏‏‎ ‏‏‎ ‎‏‏‎‎‏‏‎ ‎‏‏‎ ‎‏‏‎‎‏‏‎ ‎‏‏‎ ‏‏‎‎‏⬆️

Je soupçonne que sudo git pull a écrasé cela, puis j’ai essayé de reconstruire avec le mauvais pilote de stockage ?

Je viens de tout annuler, puis de modifier à nouveau launcher avant d’exécuter rebuild app, et tout fonctionne à nouveau.

cd /var/discourse
sudo git stash
sudo git pull
sudo nano launcher 

‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ ‎‏‏‎ puis modifier la ligne 171 pour inclure vfs

sudo ./launcher rebuild app

Salut @ajmuir ,
Je sais que vous avez résolu votre problème il y a plus d’un an, mais je voulais ajouter mon grain de sel à cette discussion et également permettre aux nouveaux utilisateurs qui trouvent ce fil de discussion de suivre la bonne voie.

Webdock (maintenant) recommande d’utiliser fuse-overlayfs comme pilote de stockage Docker : How to change the Docker storage driver – Webdock

La raison est que vfs produit une utilisation élevée de l’espace disque.

Mais l’utilisation de fuse-overlayfs pour Docker produira un avertissement ou une erreur du côté du lanceur Discourse, car ce n’est pas un pilote recommandé.

J’ai des instructions détaillées sur la façon de résoudre ce problème dans ce post sur mon blog : Deploying Discourse on a Webdock server

Vous pouvez également le faire comme vous l’avez fait en ajoutant le pilote installé à l’instruction egrep.

Et pourquoi dites-vous que Webdock ne permet pas la création d’utilisateurs root ?
Vous pouvez simplement passer à root avec sudo su et exécuter les commandes du guide d’installation de Discourse après cela.