Moin!
Ich habe hier ein CentOS 8 mit einem Postgres-DBMS was beim reboot einfach nicht "sauber" starten möchte; mir gehen langsam die Ideen aus, wo ich noch suchen soll oder was ich falsch mache. Gefühlt habe ich das Internet leer gesucht, aber keine für mich passende Lösung gefunden. Postgres läuft fröhlich in ähnlicher Konfig auf einem CentOS 7 und ich habe auch zwei Work-Arounds, die ok sind; aber ich würde eben einfach gerne verstehen, warum meine Konfig nicht läuft.
Grundsätzlich geht es um den Parameter listen_addresses. Hier soll localhost und die lokale IP rein. Ich will nicht über den Sinn/Unsinn von IP-Basierter IT-Security reden, sondern einfach nur verstehen, warum es unter CentOS 7 läuft, aber nicht unter CentOS 8. Das macht mich wahnsinnig !!11EinsElf Die Postgres-Version scheint auch kein Problem zu sein, hab 10 und 12 ausprobiert. Ersetze ich die komma-separierte Liste durch * geht's.
Beispiel listen_addresses = 'localhost,192.168.56.107'
CentOS 7 = geht CentOS 8 = Fehlermeldung
Was heißt geht? Beim Reboot und einem anschließenden systemctl status postgresql
LOG: konnte IPv4-Adresse »192.168.56.107« nicht binden: Die angeforderte Adresse kan> TIPP: Läuft bereits ein anderer Postmaster auf Port 5432? Wenn nicht, warten Sie ein> WARNUNG: konnte Listen-Socket für »192.168.56.107« nicht erzeugen
Bei netstat und lsof fehlen entsprechende Einträge, der postmaster lauscht also nicht. :(
Der Knaller: Starte ich postgres händisch durch (nach dem Reboot) ist die Warning-Meldung weg und netstat als auch lsof bestätigen ein "horchen".
erwarte Verbindungen auf IPv4-Adresse »192.168.56.107«, Port 5432
Entsprechend ist auch dann der postgres erst von extern (z.B. pgadmin) erreichbar.
Was ich so rechecheriert habe /etc/hosts-Datei lokale IP aufnehmen, Filesystem Rechte kontrolliert, firewall aus, seLinux auf permissive, keine Leichen ala /tmp/.s.PGSQL.5 nach dem händischen stoppen von postgres.
Klar kann ich in die start-Unit ExecStartPre=/bin/sleep 30 Eintragen oder eben auch listen_addresses = '*' dann kommt postgres ohne Gemecker nach oben.
Die Logdateien unter ~postgres/data/log/postgresql-Fri.log schweigen sich aus. Habe erst das Netzwerk in Verdacht gehabt, weil sich das bei dmesg im IPv6-Bereich beschwert, dass es noch nicht "ready" sei. Flugs IPv6 per Kernel-Parameter in der grub-Konfig deaktiviert, aber auch ohne Besserung bzw. noch mehr Genörgel im selinux-Bereich, was aber ein alter Bug zu sein scheint: https://bugzilla.redhat.com/show_bug.cgi?id=641836
VG Rainer
Moin,
was steht nach dem Boot denn im dmesg drin? Alternativ hilft es auch noch einmal via journalctl -xeu postgresql (o.Ä) zu prüfen. Und vielleicht zu einfach, aber einen Versuch wert - versuche einmal ein Leerzeichen zwischen listen_addresses = 'localhost,192.168.56.107' zu setzen. Also so: listen_addresses = 'localhost, 192.168.56.107'
Viele Grüße
Phil
rainer.rose@hannit.de hat am 04.03.2021 11:09 geschrieben: Moin! Ich habe hier ein CentOS 8 mit einem Postgres-DBMS was beim reboot einfach nicht „sauber“ starten möchte; mir gehen langsam die Ideen aus, wo ich noch suchen soll oder was ich falsch mache. Gefühlt habe ich das Internet leer gesucht, aber keine für mich passende Lösung gefunden. Postgres läuft fröhlich in ähnlicher Konfig auf einem CentOS 7 und ich habe auch zwei Work-Arounds, die ok sind; aber ich würde eben einfach gerne verstehen, warum meine Konfig nicht läuft. Grundsätzlich geht es um den Parameter listen_addresses. Hier soll localhost und die lokale IP rein. Ich will nicht über den Sinn/Unsinn von IP-Basierter IT-Security reden, sondern einfach nur verstehen, warum es unter CentOS 7 läuft, aber nicht unter CentOS 8. Das macht mich wahnsinnig !!11EinsElf Die Postgres-Version scheint auch kein Problem zu sein, hab 10 und 12 ausprobiert. Ersetze ich die komma-separierte Liste durch * geht’s. Beispiel listen_addresses = 'localhost,192.168.56.107' CentOS 7 = geht CentOS 8 = Fehlermeldung Was heißt geht? Beim Reboot und einem anschließenden systemctl status postgresql LOG: konnte IPv4-Adresse »192.168.56.107« nicht binden: Die angeforderte Adresse kan> TIPP: Läuft bereits ein anderer Postmaster auf Port 5432? Wenn nicht, warten Sie ein> WARNUNG: konnte Listen-Socket für »192.168.56.107« nicht erzeugen Bei netstat und lsof fehlen entsprechende Einträge, der postmaster lauscht also nicht. L Der Knaller: Starte ich postgres händisch durch (nach dem Reboot) ist die Warning-Meldung weg und netstat als auch lsof bestätigen ein „horchen“. erwarte Verbindungen auf IPv4-Adresse »192.168.56.107«, Port 5432 Entsprechend ist auch dann der postgres erst von extern (z.B. pgadmin) erreichbar. Was ich so rechecheriert habe /etc/hosts-Datei lokale IP aufnehmen, Filesystem Rechte kontrolliert, firewall aus, seLinux auf permissive, keine Leichen ala /tmp/.s.PGSQL.5 nach dem händischen stoppen von postgres. Klar kann ich in die start-Unit ExecStartPre=/bin/sleep 30 Eintragen oder eben auch listen_addresses = '*' dann kommt postgres ohne Gemecker nach oben. Die Logdateien unter ~postgres/data/log/postgresql-Fri.log schweigen sich aus. Habe erst das Netzwerk in Verdacht gehabt, weil sich das bei dmesg im IPv6-Bereich beschwert, dass es noch nicht „ready“ sei. Flugs IPv6 per Kernel-Parameter in der grub-Konfig deaktiviert, aber auch ohne Besserung bzw. noch mehr Genörgel im selinux-Bereich, was aber ein alter Bug zu sein scheint: https://bugzilla.redhat.com/show_bug.cgi?id=641836 https://bugzilla.redhat.com/show_bug.cgi?id=641836 VG Rainer -- _______________________________________________ CentOS-de mailing list CentOS-de@centos.org https://lists.centos.org/mailman/listinfo/centos-de
Mit freundlichen Grüßen,
Phil Thiele
____________________________
Phil Thiele
Geestrand 2
21435 Stelle
Tel.: 0151 507 811 81
Mail: p.thiele@mailbox.org
Moin!
Ø was steht nach dem Boot denn im dmesg drin?
IMHO nichts spannendes, außer:
[ 32.087271] IPv6: ADDRCONF(NETDEV_UP): enp0s3: link is not ready [ 32.111787] IPv6: ADDRCONF(NETDEV_UP): enp0s3: link is not ready [ 32.129630] e1000: enp0s3 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 32.130346] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s3: link becomes ready [ 32.154622] IPv6: ADDRCONF(NETDEV_UP): enp0s8: link is not ready [ 32.161680] IPv6: ADDRCONF(NETDEV_UP): enp0s8: link is not ready [ 32.163460] e1000: enp0s8 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: RX [ 32.164364] IPv6: ADDRCONF(NETDEV_CHANGE): enp0s8: link becomes ready
Hilft IMHO aber auch nicht weiter. Und dann ist die Ausgabe auch schon am Ende.
Ø Alternativ hilft es auch noch einmal via journalctl -xeu postgresql (o.Ä) zu prüfen.
Steht auch nicht viel mehr als bei
Systemctl status postgres
Ø versuche einmal ein Leerzeichen zwischen listen_addresses = 'localhost,192.168.56.107' zu setzen.
Hat leider nichts gebracht bzw. keine Änderung des Verhaltens, danke trotzdem für die Idee.
VG Rainer
On 04.03.21 11:09, rainer.rose@hannIT.de wrote:
systemctl status postgresql
LOG: konnte IPv4-Adresse »192.168.56.107« nicht binden: Die angeforderte Adresse kan> TIPP: Läuft bereits ein anderer Postmaster auf Port 5432? Wenn nicht, warten Sie ein> WARNUNG: konnte Listen-Socket für »192.168.56.107« nicht erzeugen
Versuche doch mal, die systemd unit auf
Wants=network-online.target
umzustellen.
Viele Grüße Ulf
Moin!
Versuche doch mal, die systemd unit auf
Wants=network-online.target
Das bringt so leider nichts, dafür ist die Grundidee natürlich super.
After=network-online.target
Sieht dann besser aus. Ein netstat gibt die erwartete bzw. gewünschte Ausgabe. Einzig
konnte IPv6-Adresse »::1« nicht binden: Die angeforderte Adresse kann nicht z>
wird da noch angemäkelt, aber die IPv6-Konfig ist auch nur der distributionsdefault (also dhcp). Da ich so ein modernen Tünkram eh nicht nutze, finde ich das persönlich nicht schlimm.
Die "After"-Option war IMHO der richtige und gute Hinweis; darauf bin ich einfach nicht drauf gekommen.
Danke.
VG Rainer
On 04.03.21 13:20, rainer.rose@hannIT.de wrote:
konnte IPv6-Adresse »::1« nicht binden: Die angeforderte Adresse kann nicht z>
Du schriebst im ersten Post, dass Du ipv6 per Boot Option deakiviert hast. Dann ist natürlich auch kein ::1 verfügbar.
Würde ich im Zweifel wieder zurückdrehen, ipv6 hat üblicherweise keine Nachteile.
Viele Grüße Ulf
Moin Ulf!
konnte IPv6-Adresse »::1« nicht binden: Die angeforderte Adresse kann nicht z>
Du schriebst im ersten Post, dass Du ipv6 per Boot Option deakiviert hast. Dann ist natürlich auch kein ::1 verfügbar.
Ok, das war ungenau geschrieben. Es sollte heißen "habe es *temporär* deaktiviert".
Soweit ich mich erinnern kann (vor dem Wochenende hatte ich das ausprobiert). Gab*s da einiges an Nebenwirkungen. Meldungen ala IPv6: ADDRCONF(NETDEV_ Tauchten auch nicht mehr im "dmesg" auf (zumindest per deaktivierung per grub-Parameter). Etwas Recherche in $suchmaschine förderte auch ein paar Links zutage, wo auch eher davon abgeraten wurde ipv6 zu deaktivieren, habe mir die URLs aber nicht gemerkt.
Spontaner Treffer (nur quer gelesen)
https://forums.centos.org/viewtopic.php?t=71069
Die $suchmaschine-Treffer mit der Erkenntnis, dass es nichts bringt, hat ich dazu veranlasst IPv6 wieder zu aktivieren und dann als letzten Schritt hier nachzufragen.
VG Rainer
On 04.03.21 14:18, rainer.rose@hannIT.de wrote:
konnte IPv6-Adresse »::1« nicht binden: Die angeforderte Adresse kann nicht z>
Du schriebst im ersten Post, dass Du ipv6 per Boot Option deakiviert hast. Dann ist natürlich auch kein ::1 verfügbar.
Ok, das war ungenau geschrieben. Es sollte heißen "habe es *temporär* deaktiviert".
Wenn Du ipv6 wieder aktiv hast, sollte das so aussehen:
[ulf@p330 ~]$ ip -6 addre show dev lo 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 inet6 ::1/128 scope host valid_lft forever preferred_lft forever
wenn nicht, ist das irgendwas verkehrt.
Viele Grüße Ulf
-
Phil Thiele -
rainer.rose＠hannIT.de -
Ulf Volmer