La mise à jour vers 3.3 échoue pour moi

Installation
1

J’ai essayé de mettre à niveau via l’interface utilisateur, et cela a échoué comme décrit à l’adresse :

J’ai donc restauré mon droplet à partir d’une sauvegarde, puis j’ai essayé de mettre à niveau manuellement.

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

ce qui donne ceci :

WARNING: Docker version 20.10.7 deprecated, recommend upgrade to 24.0.7 or newer.
x86_64 arch detected.

WARNING: We are about to start downloading the Discourse base image
This process may take anywhere between a few minutes to an hour, depending on your network speed

Please be patient

2.0.20240825-0027: Pulling from discourse/base
e4fff0779e6d: Pulling fs layer 
04dda0e597e7: Pulling fs layer 
0b0ac7902d91: Pulling fs layer 
1ea0327cd622: Waiting 
459f11cf96b2: Waiting 
cd49b55154ee: Waiting 
4f4fb700ef54: Pull complete 
890a63bee26b: Pull complete 
1d239a1092e9: Pull complete 
7439767d748f: Pull complete 
19e63282f9d1: Pull complete 
6da4866029f1: Pull complete 
3274548c87f4: Pull complete 
fb2589b81eef: Pull complete 
da453ab7ba03: Pull complete 
260969aca4e8: Pull complete 
0c7927423a10: Pull complete 
cfdfd8bdc03e: Pull complete 
f837c184a2c0: Pull complete 
d14903daf553: Pull complete 
01422fc4dc02: Pull complete 
e918b15c8f19: Pull complete 
3202b43401af: Pull complete 
3fa0a48e923e: Pull complete 
2f1f96b416a1: Pull complete 
b5376d8069b5: Pull complete 
259e102648be: Pull complete 
807236570b2a: Pull complete 
e98845c05b05: Pull complete 
578a5e3e249f: Pull complete 
6b0bf88c86e8: Pull complete 
9551a14ee15e: Pull complete 
8bbcc4c7a11d: Pull complete 
5aff35532071: Pull complete 
f73f45300530: Pull complete 
42888ce727c0: Pull complete 
e8467a663928: Pull complete 
d2fb91f4643c: Pull complete 
88fc9778a448: Pull complete 
2a19d28a5a17: Pull complete 
6a2d56837370: Pull complete 
933885f686e0: Pull complete 
aecf6df6a6bb: Pull complete 
33fcdcfe61e2: Pull complete 
12726a4d34c8: Pull complete 
Digest: sha256:6de68cb49198b5281f79ed9401b3fe818c854d220dcf0238549fe2f2adb19146
Status: Downloaded newer image for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
WARNING: containers/app.yml file is world-readable. You can secure this file by running: chmod o-rwx containers/app.yml
Ensuring launcher is up to date
Fetching origin
Launcher is up-to-date
Stopping old container
+ /usr/bin/docker stop -t 600 app
app
2.0.20240825-0027: Pulling from discourse/base
Digest: sha256:6de68cb49198b5281f79ed9401b3fe818c854d220dcf0238549fe2f2adb19146
Status: Image is up to date for discourse/base:2.0.20240825-0027
docker.io/discourse/base:2.0.20240825-0027
/usr/local/lib/ruby/gems/3.3.0/gems/pups-1.2.1/lib/pups.rb
/usr/local/bin/pups --stdin
I, [2024-10-15T06:14:37.390458 #1]  INFO -- : Reading from stdin
I, [2024-10-15T06:14:37.395803 #1]  INFO -- : > echo cron is now included in base image, remove from templates
I, [2024-10-15T06:14:37.398391 #1]  INFO -- : cron is now included in base image, remove from templates

I, [2024-10-15T06:14:37.408024 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown: 
I, [2024-10-15T06:14:37.412237 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown: 
I, [2024-10-15T06:14:37.416506 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown: 
I, [2024-10-15T06:14:37.420758 #1]  INFO -- : File > /root/install_postgres  chmod: +x  chown: 
I, [2024-10-15T06:14:37.424824 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown: 
I, [2024-10-15T06:14:37.425837 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/13/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.426590 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.427073 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.427713 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.428194 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.428633 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.429175 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.429569 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.430001 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/13/main/postgresql.conf
I, [2024-10-15T06:14:37.430562 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/13/main/pg_hba.conf
I, [2024-10-15T06:14:37.430964 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-10-15T06:14:37.431353 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*::1\\/128.*$) with host all all ::/0 md5 in /etc/postgresql/13/main/pg_hba.conf
I, [2024-10-15T06:14:37.431673 #1]  INFO -- : > if [ -f /root/install_postgres ]; then
  /root/install_postgres && rm -f /root/install_postgres
elif [ -e /shared/postgres_run/.s.PGSQL.5432 ]; then
  socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
fi

I, [2024-10-15T06:14:37.974529 #1]  INFO -- : Generating locales (this might take a while)...
Generation complete.

I, [2024-10-15T06:14:37.975013 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/13/bin/postmaster -D /etc/postgresql/13/main
I, [2024-10-15T06:14:37.976577 #1]  INFO -- : Terminating async processes
2024-10-15 06:14:38.136 UTC [36] LOG:  starting PostgreSQL 13.16 (Debian 13.16-1.pgdg120+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 12.2.0-14) 12.2.0, 64-bit
2024-10-15 06:14:38.138 UTC [36] LOG:  listening on IPv4 address "0.0.0.0", port 5432
2024-10-15 06:14:38.139 UTC [36] LOG:  listening on IPv6 address "::", port 5432
2024-10-15 06:14:38.143 UTC [36] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
2024-10-15 06:14:38.154 UTC [37] LOG:  database system was shut down at 2024-10-15 06:14:28 UTC
2024-10-15 06:14:38.176 UTC [36] LOG:  database system is ready to accept connections

à ce stade, la mise à niveau s’arrête, rien d’autre ne se passe et le serveur est hors ligne (aucune connexion web du tout).

Que dois-je essayer ensuite ?

2

Les mises à niveau de l’interface utilisateur nécessitent plus de mémoire, je crois, car vous essayez d’exécuter le site et de reconstruire simultanément.

Assurez-vous d’avoir suffisamment de swap pour faire face - au moins autant que votre RAM.

Donc, sur un serveur de 4 Go, assurez-vous d’avoir 4 Go de swap.

Au fait, le git pull ici est redondant. Le script de build le fait pour vous.

1 « J'aime »
3

Mon serveur dispose de 4 Go de RAM et de 4 Go de Swap. La reconstruction s’arrête simplement à database system is ready to accept connections et ne se termine pas, le forum reste hors service. Je peux le restaurer à partir de la sauvegarde du Droplet (encore une fois), ce qui me ramènera à un forum 3.2 fonctionnel, mais il serait préférable de résoudre ce problème.

# free
              total        used        free      shared  buff/cache   available
Mem:           3919         286        1443          20        2189        3360
Swap:          4095           2        4093
Total:         8015         288        5537
2 « J'aime »
4

Dans ces circonstances, je redémarre habituellement (à mes risques et périls), mais cela ne m’a pas encore fait défaut. Au moins, cela remet le site en ligne.

Assurez-vous que votre système d’exploitation est raisonnablement à jour (LTS) et que cet avertissement Docker semble valoir la peine d’être pris en compte.

Surveillez votre mémoire pendant la reconstruction avec htop pour en être sûr ?

On dirait beaucoup de swap cependant. :+1:

2 « J'aime »
5

Mon système d’exploitation est Ubuntu 20.04.6 LTS.

Hein. OK, j’ai redémarré et le forum est revenu.

Ahh, mais il indique toujours que la version installée est la 3.2.4, la dernière est la 3.3.2, donc elle n’est pas mise à jour.

Je ne suis donc pas sûr de ce qu’il en est. Je vais réessayer la mise à jour.

Oui, ça s’arrête au même endroit. Je suppose qu’une version plus récente de Docker nécessiterait une mise à jour de la version majeure d’Ubuntu, ce que je pourrais faire, je n’avais juste pas prévu de le faire pour le moment.

6

Je mettrais à jour votre OS et Docker juste pour être sûr.

Il y a parfois de gros retards dans le script de build à divers points. Quelle est la durée ?

2 « J'aime »
7

Il était bloqué à ce point quand je suis revenu après 15-20 minutes. Depuis, je n’ai pas attendu particulièrement longtemps. Il est possible qu’il soit juste en train de faire quelque chose, mais il n’y a aucune preuve de cela. Rien n’utilise de CPU appréciable.

1 « J'aime »
8

Vous avez je pense deux choix à ce stade :

  • Mise à niveau de l’OS et de Docker sur place - puis réessayer
  • Nouveau Droplet.

Ce dernier pourrait être plus rapide.

9

Eh bien, j’ai un instantané actuel, je suppose que faire une mise à niveau d’Ubuntu ne fera pas de mal à ce stade, je peux toujours tout annuler.

1 « J'aime »
10

Ah, il refuse car

Désolé, ce pilote de stockage n'est pas pris en charge dans les noyaux des versions plus récentes

Il n'y aura plus de versions Ubuntu qui fourniront une prise en charge du noyau pour le pilote de stockage aufs.

Veuillez vous assurer qu'aucun de vos conteneurs n'utilise le pilote de stockage aufs, supprimez le répertoire /var/lib/docker/aufs et réessayez.

Soupir. Rien n’est jamais facile, n’est-ce pas ?

2 « J'aime »
11

Nouveau Droplet. :).\n\nSteps involved to downgrade from 2GB to 1GB on DO? - #3 by merefield(Et n’oubliez pas de recréer le swap sur le nouveau serveur s’il n’a pas déjà été créé)

3 « J'aime »
12

OK, eh bien, l’ensemble du processus de mise à niveau peut être considéré comme un désastre sans atténuation.

Je vais rétablir le droplet à ce que j’avais auparavant (Ubuntu 20.04.6 LTS et Discord 3.2.4), mettre ma tête dans le sable et oublier tout de la version 3.3, et réessayer un autre jour.

Merci d’avoir essayé d’aider.

2 « J'aime »
13

Fonctionnalité bonus - lorsque je restaure le droplet, pour une raison quelconque, je suis déconnecté - et vous ne pouvez pas vous connecter, même en tant qu’administrateur pendant que le site est en mode lecture seule !

1 « J'aime »
14

Il me vient à l’esprit que je ne peux pas passer Docker à overlay2 comme décrit sur (Change the Docker storage backend) afin de pouvoir mettre à jour Ubuntu, car le passage à overlay nécessitera ./launcher rebuild app qui échoue (sauf si le passage à overlay2 résout le problème, mais cela seul semble peu probable). La migration vers une nouvelle gouttelette semble donc être la seule voie plausible, bien que cela nécessite ensuite probablement des changements DNS qui sont généralement assez lents. Ugh.

1 « J'aime »
15

Vous pourriez être en mesure de redémarrer le conteneur avec

  docker start app

Vous pourriez également être en mesure de résoudre votre problème avec

 apt install docker-ce docker-ce-cli

Je ne suis pas sûr du problème avec la superposition. Avez-vous effectué une mise à niveau du système d’exploitation à partir d’un ancien Ubuntu à un moment donné ?

Si vous êtes sur DigitalOcean, vous pouvez créer une IP statique pointant vers l’ancien serveur et mettre à jour le DNS pour qu’il pointe vers celui-ci. Ensuite, lorsque vous passez au nouveau serveur, il n’y a pas de délai DNS car vous pouvez rediriger l’IP vers le nouveau serveur.

2 « J'aime »
16

Oui, cela a redémarré le conteneur, mais sans aucune mise à niveau.

Je ne sais pas ce qui se passe ensuite après que le « système de base de données est prêt à accepter les connexions » dans le processus de mise à niveau, mais c’est aussi loin qu’il va et jamais plus loin (sauf si la prochaine étape prend très longtemps).

Oui, Ubuntu a été mis à jour précédemment. Donc Docker est sur aufs, il l’a toujours été.

Est-il possible de reconstruire sans mettre à niveau ? Si cela fonctionne, alors je pourrai peut-être faire passer le Docker actuel d’aufs à overlay2, ce qui signifierait potentiellement que je pourrai mettre à niveau Ubuntu vers 22, ce qui pourrait signifier que d’autres choses fonctionneront alors - mais pour le moment, je n’ai aucune idée pourquoi la mise à niveau s’arrête à ce stade, donc c’est à peu près juste de l’espoir quant à ce qui pourrait le résoudre.

17

Non, il sera mis à niveau vers le dernier commit sur la branche définie.

N’oubliez pas que la migration vers un nouveau serveur peut prendre aussi peu que 30 minutes.

18

Oui, il semble que je devrai passer par là - je suis peut-être sentimental, mais je ne voulais pas vraiment avoir à configurer un tout nouveau serveur (qui exécute quelques autres choses en plus de Discourse qui devront également être migrées) juste pour mettre à niveau le forum.

Enfin, telle est la vie de toute personne qui gère son propre serveur.

2 « J'aime »
19

Oui, il semble qu’il reste bloqué pour une raison quelconque. Je ne sais pas pourquoi, mais la mise à niveau de docker semble avoir aidé quelques sites.

Avez-vous essayé de mettre à niveau docker comme je l’ai mentionné ci-dessus ?

Vous pourriez éventuellement corriger la superposition si vous cherchiez ailleurs. C’est pourquoi je ne fais pas confiance aux mises à niveau du système d’exploitation.

20

Je ne l’ai pas fait, mais je vais essayer ça ensuite - je vais devoir planifier une autre période de maintenance - mon processus consiste toujours à arrêter le droplet et à faire un snapshot, ce qui prend pas mal de temps et constitue la plus grande partie de l’indisponibilité, mais garantit que je peux très facilement annuler le processus, ce qui s’est avéré utile à quelques reprises.

Je vais donc planifier une autre fenêtre de maintenance pour mardi, puis essayer de mettre à jour Docker (et si cela fonctionne, j’essaierai également de passer à overlay). Et si cela échoue, je passerai à l’essai d’un nouveau serveur la semaine suivante (ou peut-être le ferai-je en parallèle car je peux configurer un nouveau serveur sur un droplet de test de toute façon).

Merci.