Après la mise à jour via l’interface graphique ce matin, le site est hors service. Il semble qu’il ait tenté de passer de Postgres V15 à V18, mais que cela ait échoué. J’ai donc reconstruit depuis l’application via le lanceur, sans succès. Il y a aussi une plainte concernant VIPS /usr/local/lib/libvips.so.42
Des idées ou est-ce que je suis le seul dans ce cas ?
Il est toujours judicieux de tenter une deuxième reconstruction, surtout en cas de mise à jour de la version de la base de données. Consultez le sujet connexe :
Si vous rencontrez toujours des difficultés, veuillez coller environ 100 lignes de la sortie affichée, de préférence dans un bloc de code.
Comme le souligne Chris, bien que ce conseil soit peut-être un peu tardif pour vous :
J’ai essayé cela, mais bien sûr je n’avais pas vu le fil dont vous parlez. J’avais effectué une sauvegarde avant de commencer la mise à jour. J’ai donc pu, tout à l’heure, le faire fonctionner en mettant manuellement à jour vers PG V18 dans le conteneur, et en installant également une version plus récente de vips dans le conteneur :
Le site semble fonctionner maintenant. J’ai ensuite lancé une reconstruction complète qui a réussi, donc j’espère que tout est en ordre.
vips-8.18.4
PostgreSQL 18.4
Cela dit, je vais lire attentivement le fil que vous avez partagé, car j’ai une autre instance sur une autre machine à mettre à jour également.
MERCI Ed_S !
Il est intéressant de noter que j’ai déjà dans le fichier app.yml depuis octobre 2025 :
templates:
Est-ce que je lis mal quelque chose dans l’autre sujet ?
Je pense que cela signifie que vous avez le choix par défaut, qui consiste à ne pas figer PostgreSQL sur une version particulière, mais à prendre celle que Discourse préfère.
(Les utilisateurs figeront une version particulière lorsqu’ils verront qu’une nouvelle version arrive et qu’ils ne souhaitent pas l’adopter. Mais ils doivent agir avant qu’elle n’arrive de manière inattendue.)
Bon, soupir, donc je ne sais pas vraiment ce qui a mal tourné avec ma mise à jour ce matin, pourquoi elle a échoué. Je suis méfiant à l’idée de mettre à jour l’autre site tant que je n’aurai pas compris pourquoi celui-ci a échoué, car je ne veux pas reproduire l’échec, d’autant plus que je n’aime pas trop mettre à jour manuellement des choses dans le conteneur comme je l’ai fait pour faire fonctionner ce premier site.
Je suppose que cette mise à jour, publiée aujourd’hui, qui introduit la version 18 de PostgreSQL, nécessitera deux reconstructions. Depuis l’interface web, il n’est possible d’effectuer qu’une seule reconstruction, et si je me trompe pas, une mise à jour via l’interface web apparaîtra toujours comme ayant échoué. En réalité, elle n’a pas échoué, mais n’a été effectuée qu’à moitié.
Cette hypothèse pourrait être fausse — je ne peux pas la tester facilement.
Plusieurs personnes, moi inclus, ont déclaré ne plus utiliser le mécanisme de mise à jour web, car en cas d’échec, il faut de toute façon passer par la ligne de commande. Il est vrai que cela fonctionne 95 % du temps, voire plus. Mais comme cela échoue parfois, je ne l’utilise pas personnellement.
D’accord, bonne idée de passer par la mise à jour en ligne de commande plutôt que via l’interface graphique. Le premier site est sous Ubuntu 22.04, et le second site que je dois encore mettre à jour est sous 24.04. J’ai eu assez de surprises ce matin. Lorsque j’essaierai la mise à jour du second site uniquement via la ligne de commande, je vous tiendrai au courant. Je vois toujours les anciennes versions de vips sur le second serveur /usr/local/lib/libvips.so.42, donc j’espère que cette fois-ci, elles seront mises à jour comme il faut, contrairement à la première tentative. Merci.
OJ, juste pour être clair, ma première mise à jour de Discourse a échoué, même après une reconstruction via la CLI suite à la mise à jour de l’interface graphique. Du coup, j’ai dû mettre à jour manuellement les conteneurs vers la version 18 de PostgreSQL et de vips. J’espère un meilleur résultat pour le deuxième site. Restez à l’écoute.
C’est une situation assez désagréable.
assurez-vous de disposer d’un espace disque suffisant. Notez qu’il est recommandé dans l’autre sujet de prévoir 2 x la taille de la base de données
C’est certain, et j’ai beaucoup d’espace disque sur les deux serveurs. Voici le serveur 1
df -h /var/discourse
Système de fichiers Taille Utilisé Disponible Util% Monté sur
/dev/sda1 194G 25G 170G 13% /
Serveur 2 :
df -h /var/discourse
Système de fichiers Taille Utilisé Disponible Util% Monté sur
/dev/sda1 193G 26G 168G 14% /