Vous n'êtes pas identifié(e).
Pages : 1
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 
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.
Bon le service à fini par démarrer. Merci encore pour l'aide
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
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.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.
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 ?
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.
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 ?
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
Bonjour,
Le soucis à l'air réglé. J'ai été modifié le fichier postgresql@.service dans :
var/lib/systemd/system
j'avais déja cette ligne présente :
After=network.target
que j'ai transformé sur vos conseils en :
After=network-online.target
Merci pour votre aide.
2) d'une manière plus compliquée mais plus sûre en forçant postgres à attendre que les interfaces soient prêtes via systemd, sans changer listen_addresses. Il y a une réponse ici qui va dans ce sens:
https://stackoverflow.com/questions/622 … ot-systemd
je viens de tester en rajoutant les 2 lignes :
Wants=network-online.target
After=network.target network-online.target
dans le fichier ./etc/systemd/system/multi-user.target.wants/postgresql.service dans la section [unit] mais toujours le même soucis au reboot du serveur.
Cette erreur ressemble effectivement à ce que je supposais en #2:
2022-03-28 19:13:11.816 CEST [792] LOG: n'a pas pu lier IPv4 à l'adresse « 192.168.1.2 » : Ne peut attribuer l'adresse demandée 2022-03-28 19:13:11.816 CEST [792] ASTUCE : Un autre postmaster fonctionne-t'il déjà sur le port 5432 ? Sinon, attendez quelques secondes et réessayez. 2022-03-28 19:13:11.817 CEST [792] ATTENTION: n'a pas pu créer le socket d'écoute pour « 192.168.1.2 »dans le postgresql.conf, il doit y avoir une déclaration du style:
listen_addresses = 127.0.0.1,192.168.1.2Ca dit à postgres d'écouter sur ces deux interfaces réseau. Le problème est que si 127.0.0.1 est bien accessible dès que postgres démarre au boot, 192.168.1.2 ne l'est pas.
Ca devrait pouvoir être corrigé, soit
1) de la manière la plus simple en mettantlisten_addresses = *à la place. Le problème est que s'il y a d'autres interfaces réseau sur la machine, notamment ouvertes sur Internet, pour la sécurité c'est mauvais. Le reste du monde peut joindre votre instance postgres au lieu que ce soit limité à votre réseau local.
2) d'une manière plus compliquée mais plus sûre en forçant postgres à attendre que les interfaces soient prêtes via systemd, sans changer listen_addresses. Il y a une réponse ici qui va dans ce sens:
https://stackoverflow.com/questions/622 … ot-systemd
effectivement, je viens de voir ça dans le postgresql.conf.
Et si j'enlève 127.0.0.1 dans la conf et que je laisse uniquement l'IP locale de mon serveur à savoir 192.168.1.2 ?
EDIT : je viens de tester et Postgresql ne démarre carrément pas du tout...
si je modifie mon fichier pg_hba.conf pour lui retirer la ligne :
# IPv4 local connections:
host all all 127.0.0.1/32 md5
et que je laisse uniquement les lignes concernant l'IP local de mon serveur ainsi que les clients locaux, cela peut régler le soucis ?
EDIT : j'ai commenté la ligne dans le fichier cela n'a pas arrangé le soucis.
Le plus probable est que l'adresse réseau ne soit pas encore montée quand postgres démarre dans le contexte d'un boot, et donc il n'écoute pas dessus. Il faudrait regarder le log serveur (/var/log/postgresql/postgresql-13-main.log juste après un boot, si c'est ça il y aura des messages d'erreur à ce sujet.
Merci de votre réponse.
Voici le contenu des logs suite à un reboot du serveur :
2022-03-28 19:12:49.937 CEST [789] LOG: a reçu une demande d'arrêt rapide
2022-03-28 19:12:49.968 CEST [789] LOG: annulation des transactions actives
2022-03-28 19:12:49.969 CEST [789] LOG: processus en tâche de fond « logical replication launcher » (PID 809) a quitté avec le code de sortie 1
2022-03-28 19:12:49.972 CEST [804] LOG: arrêt en cours
2022-03-28 19:12:50.133 CEST [789] LOG: le système de base de données est arrêté
2022-03-28 19:13:11.771 CEST [792] LOG: démarrage de PostgreSQL 13.5 (Debian 13.5-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2022-03-28 19:13:11.772 CEST [792] LOG: en écoute sur IPv4, adresse « 127.0.0.1 », port 5432
2022-03-28 19:13:11.816 CEST [792] LOG: n'a pas pu lier IPv4 à l'adresse « 192.168.1.2 » : Ne peut attribuer l'adresse demandée
2022-03-28 19:13:11.816 CEST [792] ASTUCE : Un autre postmaster fonctionne-t'il déjà sur le port 5432 ?
Sinon, attendez quelques secondes et réessayez.
2022-03-28 19:13:11.817 CEST [792] ATTENTION: n'a pas pu créer le socket d'écoute pour « 192.168.1.2 »
2022-03-28 19:13:11.819 CEST [792] LOG: écoute sur la socket Unix « /var/run/postgresql/.s.PGSQL.5432 »
2022-03-28 19:13:11.896 CEST [805] LOG: le système de bases de données a été arrêté à 2022-03-28 19:12:50 CEST
2022-03-28 19:13:11.977 CEST [792] LOG: le système de bases de données est prêt pour accepter les connexions
Merci d'avance pour votre aide.
Bonjour,
J'espère ne pas me tromper de section afin d'exposer mon problème.
J'ai un serveur perso chez moi avec Debian 11 (totalement à jour) et Postgresql 13.
J'ai installé sur ce serveur quelques applications qui utilisent postgresql (Nextcloud, Wallabag, ..) et je développe aussi un peu de SQL depuis mes pc clients sur mon LAN.
Le soucis est que lorsque je dois redémarrer mon serveur pour une raison X ou Y, mon instance postgresql n'est pas accessible immédiatement après le boot.
je précise que j'ai bien entendu enable le service avec ces 2 commandes :
sudo systemctl enable postgresql
sudo update-rc.d postgresql enable
rien à y faire, après un reboot mon instance n'est pas accessible par mes applications ou par moi-même lorsque je veux développer. DBeaver me renvoie cette erreur par exemple :
Connection to server_ip:port refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
La seule chose que j'ai a faire pour pouvoir rendre mon instance accessible est
sudo systemctl restart postgresql
Mon fichier start.conf présent dans /etc/postgresql/13/main/ est bien remplie avec la valeur "auto".
Et lorsque je reboot mon serveur et que je controle juste après le statut du service postgres j'ai ça en retour :
postgresql.service - PostgreSQL RDBMS
Loaded: loaded (/lib/systemd/system/postgresql.service; enabled; vendor preset: enabled)
Active: active (exited) since Mon 2022-03-28 12:48:30 CEST; 2min 10s ago
Process: 958 ExecStart=/bin/true (code=exited, status=0/SUCCESS)
Main PID: 958 (code=exited, status=0/SUCCESS)
CPU: 1ms
Il faut que je "restart" le service pour que mes applications (et moi-même) puissent accéder à mes bases.
Je ne sais vraiment pas ou chercher, et je tourne en ronds depuis quelques semaines.
Merci d'avance pour l'aide que vous pourrez m'apporter.
J'ai finalement désinstallé pgadmin et réinstallé.
Sujet résolu.
Bonjour à tous,
Petit soucis de connection à mon interface PGadmin4. Depuis quelques jours je n'arrive plus à afficher l'interface de pgadmin4.
j'ai une erreur 503 avec comme message :
Service Unavailable
The server is temporarily unable to service your request due to maintenance downtime or capacity problems. Please try again later.
Apache/2.4.52 (Debian) Server at 192.168.1.2 Port 80
Dans les logs d'apache j'ai cette erreur :
[Sun Feb 27 19:54:28.551976 2022] [wsgi:error] [pid 3020327] (13)Permission denied: [client 192.168.1.4:46354] mod_wsgi (pid=3020327): Unable to connect to WSGI daemon process 'pgadmin' on '/var/run/apache2/wsgi.3011766.0.1.sock' as user with uid=1001.
le user id 1001 est mon user nextcloud. je ne sais pas pourquoi pgadmin4 veut utiliser ce user que j'avais dédié a nextcloud. j'aimerais lui faire utiliser www-data
j'ai essayé de rajouter cette option dans le virtual host de pgadmin dans apache :
WSGIDaemonProcess user=www-data group=www-data
mais rien n'y fait, j'ai toujours mon erreur 503 à l'affichage. Mon dossier usr/pgadmin4 (et tout le contenu récursivement) appartient bien à www-data et au groupe www-data
Merci d'avance pour votre aide.
Super merci cela fonctionne maintenant.
je passe le sujet en résolu.
Alors je viens de configurer le postgresql.conf avec la ligne suivante (la seconde IP est celle de mon serveur):
listen_addresses = '127.0.0.1,192.168.1.86' # what IP address(es) to listen on;
et le pg_hba.conf (la seconde IP est celle de mon PC client)
# IPv4 local connections:
host all all 127.0.0.1/32 md5
host all all 192.168.1.87 md5
Et après avoir stoper postgreSQL et relancer ensuite (avec systemctl)
- Toujours impossible de me connecter depuis le client. Avec la même erreur que depuis le début.
- J'ai le service PostgreSQL Cluster 13-main qui ne veut plus démarrer. et dans les logs j'ai ça quand je tente de le redémarrer :
2021-11-03 21:29:18.461 CET [1675] LOG: démarrage de PostgreSQL 13.4 (Debian 13.4-0+deb11u1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
2021-11-03 21:29:18.461 CET [1675] LOG: en écoute sur IPv4, adresse « 127.0.0.1 », port 5432
2021-11-03 21:29:18.463 CET [1675] LOG: en écoute sur IPv4, adresse « 192.168.1.86 », port 5432
2021-11-03 21:29:18.463 CET [1675] LOG: écoute sur la socket Unix « /var/run/postgresql/.s.PGSQL.5432 »
2021-11-03 21:29:18.467 CET [1675] LOG: méthode d'authentification « 192.168.1.87 » invalide
2021-11-03 21:29:18.467 CET [1675] CONTEXTE : ligne 97 du fichier de configuration « /etc/postgresql/13/main/pg_hba.conf »
2021-11-03 21:29:18.467 CET [1675] FATAL: n'a pas pu charger pg_hba.conf
2021-11-03 21:29:18.470 CET [1675] LOG: le système de base de données est arrêté
pg_ctl : n'a pas pu démarrer le serveur
Examinez le journal applicatif.
Mais dans listen_addresses c'est quoi qu'il faut mettre ? J'ai laissé le 127.0.0.1 et l'IP qui termine en 87 c'est celle de mon PC client avec lequel je tente de me connecter au serveur. Mon serveur lui se termine en 86.
Merci d'avance pour l'aide
Voila les retours des commandes.
pg_lsclusters
Ver Cluster Port Status Owner Data directory Log file
13 main 5432 online postgres /var/lib/postgresql/13/main /var/log/postgresql/postgresql-13-main.log
SELECT name, current_setting(name) FROM pg_settings WHERE source <> 'default';
name | current_setting
----------------------------+-----------------------------------------
application_name | psql
client_encoding | UTF8
cluster_name | 13/main
config_file | /etc/postgresql/13/main/postgresql.conf
data_checksums | off
data_directory | /var/lib/postgresql/13/main
DateStyle | ISO, DMY
default_text_search_config | pg_catalog.french
dynamic_shared_memory_type | posix
external_pid_file | /var/run/postgresql/13-main.pid
hba_file | /etc/postgresql/13/main/pg_hba.conf
ident_file | /etc/postgresql/13/main/pg_ident.conf
lc_collate | fr_FR.UTF-8
lc_ctype | fr_FR.UTF-8
lc_messages | fr_FR.UTF-8
lc_monetary | fr_FR.UTF-8
lc_numeric | fr_FR.UTF-8
lc_time | fr_FR.UTF-8
listen_addresses | 127.0.0.1,192.168.1.87
log_line_prefix | %m [%p] %q%u@%d
log_timezone | Europe/Paris
max_connections | 100
max_stack_depth | 2MB
max_wal_size | 1GB
min_wal_size | 80MB
port | 5432
server_encoding | UTF8
shared_buffers | 128MB
ssl | on
ssl_cert_file | /etc/ssl/certs/ssl-cert-snakeoil.pem
ssl_key_file | /etc/ssl/private/ssl-cert-snakeoil.key
stats_temp_directory | /var/run/postgresql/13-main.pg_stat_tmp
TimeZone | Europe/Paris
transaction_deferrable | off
transaction_isolation | read committed
transaction_read_only | off
unix_socket_directories | /var/run/postgresql
wal_buffers | 4MB
wal_segment_size | 16MB
(39 lignes)
Oui j'ai bien redémarré le serveur postgresql après modifications.
J'arrive bien a me connecter en local a la base directement depuis le serveur.
J'ai été voir dans les logs postgresql sur le serveur et aucune trace de mes tentatives de connexions infructueuses.
On dirait que mon client n'arrive pas a atteindre le serveur.
Alors je viens de tenter la commande suivante directement depuis le serveur :
psql -h ip-du-client
et voici le retour :
psql: erreur : n'a pas pu se connecter au serveur : Connexion refusée
Le serveur est-il actif sur l'hôte « ip-du-client » et accepte-t-il les connexions
TCP/IP sur le port 5432 ?
merci pour l'aide
Bonjour,
Je viens sur ce forum pour m'aider à me dépatouiller d'un soucis de connexion à mon serveur postgreSQL en local.
J'ai un home server sous Debian 11 sur lequel j'ai installé Postgresql sans soucis.
Depuis mon PC (client) j'ai installé dbeaver afin d'essayer de me connecter à postgresql sur mon serveur.
J'ai d'abord créé un user avec password directement sur mon serveur dans la base postgreSQL(pour ne par avoir à utiliser le user 'postgres' de base).
Ensuite dans dbeaver, dans le paramétrage de la connexion, j'ai bien renseigné les infos suivantes :
- l'hôte : l'IP de mon serveur (qui est fixe).
- port : 5432 (le port par défaut que j'ai bien entendu ouvert dans le firewell UFW que j'ai sur mon serveur)
- user : le nom du user que j'ai créé
- password : le password que j'ai créé en même temps que le user.
Au moment de du test de la connexion, j'ai une erreur :
Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.
J'ai été modifié le fichier de conf pour mettre '*' sur la ligne listen_adress. Mais rien n'y fait.
Merci d'avance pour votre aide.
Pages : 1