Vous n'êtes pas identifié(e).
Bonjour,
J'ai mis à jour mon serveur perso (auto-hébergé) de Debian 11 à Debian 12.
Tout s'est passé correctement sauf le service postgres qui ne veut plus démarrer.
Voila ce que m'affiche Postgres au moment ou je tente de le démarrer (via mon Cockpit) :
22:43 Failed to start postgresql@15-main.service - PostgreSQL Cluster 15-main.
22:43 postgresql@15-main.service: Failed with result 'protocol'.
22:43 postgresql@15-main.service: Can't open PID file /run/postgresql/15-main.pid (yet?) after start: No such file or directory
22:43 Cluster is already running.
22:43 Starting postgresql@15-main.service - PostgreSQL Cluster 15-main....Et le service refuse toujours de démarrer.
Merci d'avance pour l'aide que vous m'apporterez.
A bientôt
Dernière modification par GrosJambon33000 (24/11/2023 01:14:30)
Hors ligne
Bonjour,
Il devrait y avoir plus d'info dans les logs de postgres plutôt que les logs du service, pouvez-vous nous montrer le contenu de ceux-ci ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Il devrait y avoir plus d'info dans les logs de postgres plutôt que les logs du service, pouvez-vous nous montrer le contenu de ceux-ci ?
Merci de la réponse.
Malheureusement, rien dans les logs de postgresql. A chaque tentative de démarrage du service, strictement aucun log n'est ajouté au fichier postgresql-15-main.log.
Les dernières log que j'ai dans ce fichiers sont les tentatives de requêtes (échoués) que j'avais lancer sous dbeaver et qui m'ont fait remarquer que le service ne tournait plus. c'était il y a maintenant 2 jours. Et depuis j'ai tenté de redémarrer Postgresql un bon nombre de fois !
Ils est vraiment pas bavard postgresql pour le coup...
Et cette histoire de PID file manquant ? je pense que ça doit être lié non ?
Dernière modification par GrosJambon33000 (21/11/2023 11:33:37)
Hors ligne
Le fichier de pid est créé par postgres lors du démarrage, son absence indique donc sans surprise un problème de démarrage. Vous pouvez vérifier à tout hasard si le /run/postgresql/ existe bien et est accessible par postgres, mais si ce n'était pas le cas il devrait y avoir des info dans les logs.
Peut-être avez-vous un autre fichier de log, type startup.log, pour ce qui pourrait être généré avant que postgres ne démarre le log collector (si c'est ce que vous utilisez). Sinon peut être que journalctl (ou ce que vous utilisez) à plus d'informations ?
Julien.
https://rjuju.github.io/
Hors ligne
Le fichier de pid est créé par postgres lors du démarrage, son absence indique donc sans surprise un problème de démarrage. Vous pouvez vérifier à tout hasard si le /run/postgresql/ existe bien et est accessible par postgres, mais si ce n'était pas le cas il devrait y avoir des info dans les logs.
le dossier existe bien, et Postgres y a bien accès (owner = postgres et dans dans le group postgres également)
Peut-être avez-vous un autre fichier de log, type startup.log, pour ce qui pourrait être généré avant que postgres ne démarre le log collector (si c'est ce que vous utilisez). Sinon peut être que journalctl (ou ce que vous utilisez) à plus d'informations ?
dans var/log/postgresql je n'ai pas de startup.log malheureusement. ni même dans var/log/ d'ailleurs.
Pour ce qui est de journalctl la commande :
journalctl -u postgresql@15-main.servicene retourne rien du tout.
Par contre une chose que j'ai oublié de préciser c'est que j'ai également un autre service postgresql d'un ancienne version (celle d'avant mon upgrade de debian 11 à 12 je pense) qui est toujours présent et refuse de démarrer également.
Pour autant le message d'erreur n'est pas le même.
11:52 Assertion failed for postgresql@13-main.service - PostgreSQL Cluster 13-main.
11:52 postgresql@13-main.service: Starting requested but asserts failed.je ne comprends pas pourquoi j'ai encore ce service qui est existant.
Quand j'envoie cette commande :
/usr/lib/postgresql/15/bin/postgres -Vle retour me donne bien :
postgres (PostgreSQL) 15.5 (Debian 15.5-0+deb12u1) est-ce que la présence de ce service (d'une ancienne version) qui traine peut être la cause de mon soucis ?
merci d'avance pour la réponse.
Dernière modification par GrosJambon33000 (21/11/2023 15:43:23)
Hors ligne
Que vous dit pg_lsclusters? Utilisiez vous pg15 ou pg13 avant la mise à jour de debian? De pus, utilisez vous les paquets de debian ou du pgdg?
Julien.
https://rjuju.github.io/
Hors ligne
Que vous dit pg_lsclusters?
Voila le retour de cette commande :
Ver Cluster Port Status Owner Data directory Log file
15 main 5432 down postgres /var/lib/postgresql/15/main /var/log/postgresql/postgresql-15-main.logUtilisiez vous pg15 ou pg13 avant la mise à jour de debian?
pg13
De pus, utilisez vous les paquets de debian ou du pgdg?
Bonne question... ça fait longtemps que je l'ai installé, me souviens plus trop. y'a un moyen de le savoir ?
Hors ligne
pg13
Si vous utilisiez pg13 avant la mise à jour de Debian et que pg_lsclusters indique maintenant une unique instance avec pg15, vous avez à priori un gros problème.
Juste au cas où, que contient le fichier /var/lib/postgresql/15/main/PG_VERSION ? Avez-vous d'autres répertoires dans le répertoire /var/lib/postgresql/ ?
Bonne question... ça fait longtemps que je l'ai installé, me souviens plus trop. y'a un moyen de le savoir ?
Vous pouvez faire un "apt list | grep postgres". Si les noms des paquets finissent avec "...+debXXX" ils proviennent du repo de debian, sinon ils devraient finir avec "+pgdgXXX" pour le repo du pgdg.
Julien.
https://rjuju.github.io/
Hors ligne
pg13
Si vous utilisiez pg13 avant la mise à jour de Debian et que pg_lsclusters indique maintenant une unique instance avec pg15, vous avez à priori un gros problème.
Juste au cas où, que contient le fichier /var/lib/postgresql/15/main/PG_VERSION ? Avez-vous d'autres répertoires dans le répertoire /var/lib/postgresql/ ?
Le fichier contient la valeur 15 seulement.
Et dans /var/lib/postgresql j'ai seulement le dossier nommé 15.
Bonne question... ça fait longtemps que je l'ai installé, me souviens plus trop. y'a un moyen de le savoir ?
Vous pouvez faire un "apt list | grep postgres". Si les noms des paquets finissent avec "...+debXXX" ils proviennent du repo de debian, sinon ils devraient finir avec "+pgdgXXX" pour le repo du pgdg.
La plupart des noms des paquets ne terminent ni avec debXXX ni avec pgdgXXX.
Par contre certains finissent par debXXX et aucun ne finit par pgdgXXX.
Hors ligne
Le fichier contient la valeur 15 seulement.
Et dans /var/lib/postgresql j'ai seulement le dossier nommé 15.
C'est donc effectivement les données d'une instance en version 15. Si vous utilisiez postgres 13 auparavant, je ne sais pas ce qu'il s'est passé mais vos données ne sont plus là. Ou peut être avez-vous effectué un pg_upgrade (ou pg_upgradecluster, il me semble que le packaging debian fournit un wrapper pour cela)?
La plupart des noms des paquets ne terminent ni avec debXXX ni avec pgdgXXX.
Par contre certains finissent par debXXX et aucun ne finit par pgdgXXX.
Ok, donc vous avez les paquets debian.
Pour en revenir à votre problème original, je ne vois pas trop comment aider sans avoir plus de logs. Peut-être pouvez vous essayer de démarrer postgres avec pg_ctlcluster, ou directement avec pg_ctl et obtenir les logs manquants? Vous pouvez sinon vérifier la configuration de postgres pour vous asurer que les logs vont bien dans le répertoire en question et que les droits sur ce répertoire sont ok, ou la documentation des paquets debian pour savoir où se trouvent les logs qui surviennent dans ce genre de situation.
Julien.
https://rjuju.github.io/
Hors ligne
Vous pouvez provisoirement zapper les couches systemd et pg_ctlcluster en lançant à la main avec cette commande en qu'utilisateur postgres:
/usr/lib/postgresql/15/bin/pg_ctl \
-D /var/lib/postgresql/15/main \
-o "-c config_file=/etc/postgresql/15/main/postgresql.conf" \
startLe but n'étant pas tant de démarrer que d'avoir des erreurs à l'affichage, si ni /var/log/postgresql/postgresql-15-main.log ni journalctl -u postgresql@15-main.service ne donnent pas d'indication.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Vous pouvez provisoirement zapper les couches systemd et pg_ctlcluster en lançant à la main avec cette commande en qu'utilisateur postgres:
/usr/lib/postgresql/15/bin/pg_ctl \ -D /var/lib/postgresql/15/main \ -o "-c config_file=/etc/postgresql/15/main/postgresql.conf" \ startLe but n'étant pas tant de démarrer que d'avoir des erreurs à l'affichage, si ni /var/log/postgresql/postgresql-15-main.log ni journalctl -u postgresql@15-main.service ne donnent pas d'indication.
Merci cela commence à être plus bavard côté postgresql :
pg_ctl : un autre serveur semble en cours d'exécution ; le démarrage du serveur
va toutefois être tenté
en attente du démarrage du serveur....2023-11-22 23:24:28.670 CET [6532] FATAL: le fichier verrou « postmaster.pid » existe déjà
2023-11-22 23:24:28.670 CET [6532] ASTUCE : Un autre postmaster (de PID 1097) est-il déjà lancé avec comme répertoire de
données « /var/lib/postgresql/15/main » ?
attente arrêtée
pg_ctl : n'a pas pu démarrer le serveur
Examinez le journal applicatif.Hors ligne
Si le service n'est vraiment pas démarré (il est important de vraiment s'en assurer), supprimer les fichiers postmaster.* pourrait résoudre le problème.
Julien.
https://rjuju.github.io/
Hors ligne
Le fichier /var/lib/postgresql/15/main/postmaster.pid a un contenu du style:
1206
/var/lib/postgresql/15/main
1700725615
5432
/var/run/postgresql
localhost
11796503 0
ready où le nombre de la 1ere ligne est le numéro de processus PID que postmaster avait la dernière fois qu'il a tourné.
En cas d'arrêt normal ce fichier est effacé, en cas de reboot il ne peut pas l'être.
Dans votre cas, ce numéro de processus doit être maintenant constamment utilisé par un autre processus, sinon postgres effacerait le fichier et démarrerait quand même. C'est pourquoi il faut l'effacer à la main.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Le fichier /var/lib/postgresql/15/main/postmaster.pid a un contenu du style:
1206 /var/lib/postgresql/15/main 1700725615 5432 /var/run/postgresql localhost 11796503 0 readyoù le nombre de la 1ere ligne est le numéro de processus PID que postmaster avait la dernière fois qu'il a tourné.
En cas d'arrêt normal ce fichier est effacé, en cas de reboot il ne peut pas l'être.Dans votre cas, ce numéro de processus doit être maintenant constamment utilisé par un autre processus, sinon postgres effacerait le fichier et démarrerait quand même. C'est pourquoi il faut l'effacer à la main.
Merci a tous de vos réponses.
Donc si je comprends bien j'ai juste a supprimer le fichier /var/lib/postgresql/15/main/postmaster.pid puis tenter de redémarrer le service qui concerne la version 15 de postgres ?
Et comment faire pour virer ce service qui traine concernant la version 13 ?
Merci encore pour l'aide 
Dernière modification par GrosJambon33000 (23/11/2023 12:22:57)
Hors ligne
Bon le service à fini par démarrer. Merci encore pour l'aide
Hors ligne
Et comment faire pour virer ce service qui traine concernant la version 13 ?
Il serait intéressant de voir ce que sortent ces commandes:
dpkg --get-selections 'postgres*'
systemctl list-units 'postgres*'@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Et comment faire pour virer ce service qui traine concernant la version 13 ?
Il serait intéressant de voir ce que sortent ces commandes:
dpkg --get-selections 'postgres*' systemctl list-units 'postgres*'
voila le retour de cette commande
postgresql install
postgresql-13 deinstall
postgresql-15 install
postgresql-client-15 install
postgresql-client-common install
postgresql-common install
postgresql-contrib install
UNIT LOAD ACTIVE SUB DESCRIPTION
postgresql.service loaded active exited PostgreSQL RDBMS
postgresql@15-main.service loaded active running PostgreSQL Cluster 15-main
LOAD = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB = The low-level unit activation state, values depend on unit type.
2 loaded units listed. Pass --all to see loaded but inactive units, too.
To show all installed unit files use 'systemctl list-unit-files'.en fait j'ai l'impression que mon soucis n'est pas tant résolu que ça parce que pour faire simple, j'ai une instance Nextcloud sur mon serveur également. J'avais mis en place une connexion avec dbeaver pour pouvoir requêter dans la bdd de mon instance, j'utilisais mon user perso pour requêter et non le user dedié a nextcloud, et depuis l'upgrade vers debian 12 mon user perso n'a plus le droit de rien faire sur le schema qui contient les données de mon instance nextcloud.
Hors ligne
Concernant l'ancien postgresql 13, tout a l'air OK: le package et l'unité systemd sont désinstallés.
Donc ça pose la question de savoir pourquoi ce message cité en #5 apparait
11:52 Assertion failed for postgresql@13-main.service - PostgreSQL Cluster 13-main.
11:52 postgresql@13-main.service: Starting requested but asserts failed."Starting requested" mais par quoi? Il doit rester une dépendance sur ce service quelque part.
Concernant les droits du user perso, le schéma en question est peut-être "public", et il se trouve que les permissions données à public ont été restreintes dans Postgres 15. Il faut maintenant donner les permissions explicitement aux utilisateurs en-dehors du possesseur de la BDD. En théorie lors d'un upgrade ce problème n'apparait pas car "public" est censé être migré avec ses permissions d'avant.
@DanielVerite
http://blog-postgresql.verite.pro/
Hors ligne
Concernant l'ancien postgresql 13, tout a l'air OK: le package et l'unité systemd sont désinstallés.
Donc ça pose la question de savoir pourquoi ce message cité en #5 apparait11:52 Assertion failed for postgresql@13-main.service - PostgreSQL Cluster 13-main. 11:52 postgresql@13-main.service: Starting requested but asserts failed."Starting requested" mais par quoi? Il doit rester une dépendance sur ce service quelque part.
Concernant les droits du user perso, le schéma en question est peut-être "public", et il se trouve que les permissions données à public ont été restreintes dans Postgres 15. Il faut maintenant donner les permissions explicitement aux utilisateurs en-dehors du possesseur de la BDD. En théorie lors d'un upgrade ce problème n'apparait pas car "public" est censé être migré avec ses permissions d'avant.
Je ne vois vraiment pas comment trouver la dépendance qu'il peut rester quelque part.
Pour le problème de droit je ne sais pas non plus quoi te répondre.
Merci en tout cas pour l'aide
Hors ligne