Postgresql me fait des misères

stemy2 · Juillet 31, 2020, 9:31

Bonjour,

J’ai tenté une migration vers yunohost 4.x et ça s’est mal passé.

Tentative échouée pour cause de perte de connexion.
MAJ des paquets restants.
MAJ des paquets système en arrière plan qui ne fonctionne pas.
Lancement de la migration via la console locale.
pgsql n’arrive pas à migrer vers la version 11.
Tentative de dist-upgrade, qui empire la situation (nginx ne démarre plus).
Commande apt install yunohost openssl, le serveur se comporte comme si il était remis à zéro mais tous les services fonctionnent.
Tout semble revenu à la normale (ou presque), mais il me demande de faire la config de base et la postinstall.
Commande touch /etc/yunohost/installed, tout semble rentrer dans l’ordre (ou presque, encore une fois).
Après vérification, plus aucune app utilisant pgsql ne fonctionne.
Le service est marqué comme inactive (dead) et impossible de le démarrer.
Réinstallation de pgsql à l’aide de la commande apt purge.
Le service est marqué comme active (running) mais les apps concernées ne fonctionnent toujours pas, y compris à l’installation.

Voilà où j’en suis actuellement. Et je ne sais plus quelle piste explorer.

cquest · Juillet 31, 2020, 2:31

‹ pg_dropcluster --stop 11 main › returned non-zero exit status 127

Le script de yunohost tente de supprimer le cluster PG installé par défaut avec le paquet. Peut-être n’existe-il pas.

Vérifie la liste des clusters PG existants avec

pg_lsclusters

Tu auras le status de chaque par la même occasion (online/offline) en vert ou rouge…

stemy2 · Juillet 31, 2020, 3:08

9.6 main    5432 down   postgres /var/lib/postgresql/9.6/main /var/log/postgresql/postgresql-9.6-main.log
11  main    5433 online postgres /var/lib/postgresql/11/main  /var/log/postgresql/postgresql-11-main.log

C’est le 9.6 qui est en rouge. Le problème, c’est que j’ai désinstallé cette même version, et elle est absente des dépôts actuellement configurés.

cquest · Août 1, 2020, 6:38

Le pg_dropcluster ne devrait pas retourner d’erreur vu qu’il y a bien un serveur 11/main (et actif).

Il y a visiblement un problème avec le script d’upgrade de yunohost… il faut regarder ce qu’il veut faire et comprendre ce qui coince.

C’est la limite de ces surpackaging (yunohost) qui deviennent une galère quand tout ne se passe pas comme prévu par des scripts qui ne peuvent jamais tout prévoir.
C’est là où la connaissance des briques essentielles remet l’humain sysadmin en première ligne.

stemy2 · Août 1, 2020, 8:24

Et il se trouve où, ce fameux script ?

cquest · Août 1, 2020, 9:46

D’après ton log d’erreur…

/usr/lib/moulinette/yunohost/data_migrations/0017_postgresql_9p6_to_11.py

Il est appelé par /usr/lib/moulinette/yunohost/tools.py

PS: je n’utilise pas yunohost

stemy2 · Août 1, 2020, 10:21

Le contenu dudit fichier.

import subprocess

from moulinette import m18n
from yunohost.utils.error import YunohostError
from moulinette.utils.log import getActionLogger

from yunohost.tools import Migration
from yunohost.utils.filesystem import free_space_in_directory, space_used_by_directory

logger = getActionLogger('yunohost.migration')


class MyMigration(Migration):

    "Migrate DBs from Postgresql 9.6 to 11 after migrating to Buster"

    dependencies = ["migrate_to_buster"]

    def run(self):

        if not self.package_is_installed("postgresql-9.6"):
            logger.warning(m18n.n("migration_0017_postgresql_96_not_installed"))
            return

        if not self.package_is_installed("postgresql-11"):
            raise YunohostError("migration_0017_postgresql_11_not_installed")

        if not space_used_by_directory("/var/lib/postgresql/9.6") > free_space_in_directory("/var/lib/postgresql"):
            raise YunohostError("migration_0017_not_enough_space", path="/var/lib/postgresql/")

        subprocess.check_call("systemctl stop postgresql", shell=True)
        subprocess.check_call("pg_dropcluster --stop 11 main", shell=True)
        subprocess.check_call("pg_upgradecluster -m upgrade 9.6 main", shell=True)
        subprocess.check_call("pg_dropcluster --stop 9.6 main", shell=True)
        subprocess.check_call("systemctl start postgresql", shell=True)

    def package_is_installed(self, package_name):

        p = subprocess.Popen("dpkg --list | grep '^ii ' | grep -q -w {}".format(package_name), shell=True)
        p.communicate()
        return p.returncode == 0

cquest · Août 1, 2020, 1:27

Problème à signaler sur le repo/forum/site de yunohost… car il n’y a rien de louche dans ce script.

Tu as un backup ?

Si oui, tu peux tenter l’upgrade PG à la main:

systemctl stop postgresql
pg_dropcluster --stop 11 main
pg_upgradecluster -m upgrade 9.6 main
pg_dropcluster --stop 9.6 main
systemctl start postgresql

Explications:

stoppe les serveurs postgresql
suppression de la base par défaut installée par le package PG11
upgrade des bases 9.6 en 11
suppression des bases 9.6
démarre postgres à nouveau

Tu dois pouvoir relancer le script de migration, il teste au tout début si PG9.6 est là, si il n’est pas là, il y a juste un warning et il devrait continuer avec le reste.

Mais à faire avec un backup préalable ou après un snapshot de ta VM si tu utilises une techno le permettant.

Le mieux serait quand même de te tourner vers les forums/support de yunohost…

stemy2 · Août 1, 2020, 1:36

En fait, je demande de l’aide un peu partout parce que c’est difficile d’obtenir des réponses, et c’est assez urgent parce que c’est des services que j’utilise beaucoup.

Quant à ta méthode, elle n’a pas fonctionné, ça m’a donné le message d’erreur suivant:

Error: pg_controldata not found, please install postgresql-9.6

ce que je ne peux pas faire puisqu’il n’est pas dans les dépôts.

Maintenant, pgsql est active (exited) et pg_lsclusters donne des résultats vides.

Je crois que je vais me résoudre à la restauration du backup.