Comment désactiver Postgres d'écouter sur IPv6?
J'essaie de désactiver Postgres d'écouter sur IPv6 en raison d'un tas de fichiers de trace étranges qui sont constamment écrits dans syslog.
Je préfère ne pas désactiver IPv6 dans le système d'exploitation lui-même, donc après avoir vu la mention des messages de trace et trouvé le billet de blog Désactiver IPv6 Postgres et PGBouncer , j'ai suivi l'étape 2 et mis à jour postgresql.conf (en changeant "*" en "0.0.0.0"):
# grep listen postgresql.conf
listen_addresses = '0.0.0.0'
J'ai également trouvé cette entrée dans pg_hba.conf et l'a commenté:
# IPv6 local connections:
#Host all all ::1/128 trust
J'ai redémarré Postgres. netstat semble montrer qu'il n'écoute plus sur IPv6:
# netstat -ntl | grep 5432
tcp 0 0 0.0.0.0:5432 0.0.0.0:* LISTEN
Il semble que lsof ait une idée différente:
# lsof -i6 | grep postgres
postmaste 37921 postgres 8u IPv6 39125550 0t0 UDP
localhost:38892->localhost:38892
postmaste 37944 postgres 8u IPv6 39125550 0t0 UDP
localhost:38892->localhost:38892
postmaste 37945 postgres 8u IPv6 39125550 0t0 UDP
localhost:38892->localhost:38892
<snip>
Serait-ce un bug? Ou est-ce que je manque quelque chose d'évident ici?
Le système est:
Oracle Linux 6.9
Noyau 3.8.13-118.20.2.el6uek.x86_64
PostgreSQL 9.3.21
Fichier de trace de syslog:
Mar 9 13:36:35 atlassiandb100 kernel: ------------[ cut here ]------------
Mar 9 13:36:35 atlassiandb100 kernel: WARNING: at net/core/dst.c:285 dst_release+0x79/0x80()
Mar 9 13:36:35 atlassiandb100 kernel: Hardware name: PowerEdge R630
Mar 9 13:36:35 atlassiandb100 kernel: Modules linked in: ipmi_si Dell_rbu nfsv3 nfs_acl nfsv4 auth_rpcgss nfs fscache lockd sunrpc 8021q garp stp llc bonding ipv6 ext3 jbd ext2 dm_queue_length dm_multipath dcdbas shpchp sg bnx2x ptp pps_core libcrc32c mdio coretemp hwmon kvm_intel kvm microcode pcspkr ipmi_devintf ipmi_msghandler ext4 jbd2 mbcache sd_mod crc_t10dif ghash_clmulni_intel crc32c_intel aesni_intel ablk_helper cryptd lrw aes_x86_64 xts gf128mul ahci libahci qla2xxx scsi_transport_fc scsi_tgt megaraid_sas mxm_wmi wmi dm_mirror dm_region_hash dm_log dm_mod [last unloaded: ipmi_si]
Mar 9 13:36:35 atlassiandb100 kernel: Pid: 35856, comm: postmaster Tainted: G W 3.8.13-118.20.2.el6uek.x86_64 #2
Mar 9 13:36:35 atlassiandb100 kernel: Call Trace:
Mar 9 13:36:35 atlassiandb100 kernel: <IRQ> [<ffffffff8106149f>] warn_slowpath_common+0x7f/0xc0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff810a0b79>] ? update_rq_runnable_avg+0xd9/0x1d0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff810614fa>] warn_slowpath_null+0x1a/0x20
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814dcab9>] dst_release+0x79/0x80
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa084c0c9>] udpv6_queue_rcv_skb+0x2b9/0x370 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa084c725>] __udp6_lib_rcv+0x255/0x600 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff81096a15>] ? ttwu_do_wakeup+0x45/0x100
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa084cae5>] udpv6_rcv+0x15/0x20 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0833929>] ip6_input_finish+0x179/0x3a0 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0833ba8>] ip6_input+0x58/0x60 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa08332eb>] ip6_rcv_finish+0x2b/0xb0 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0833630>] ipv6_rcv+0x2c0/0x440 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814d7dde>] __netif_receive_skb+0x56e/0x770
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff81096875>] ? scheduler_tick+0x115/0x150
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814d80e3>] process_backlog+0x103/0x1f0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814d8905>] net_rx_action+0x105/0x2b0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff8106a0f7>] __do_softirq+0xd7/0x240
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff815ae03c>] ? call_softirq+0x1c/0x30
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff815ae03c>] call_softirq+0x1c/0x30
Mar 9 13:36:35 atlassiandb100 kernel: <EOI> [<ffffffff810174f5>] do_softirq+0x65/0xa0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff81069f94>] local_bh_enable+0x94/0xa0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814d6f01>] dev_queue_xmit+0x1a1/0x410
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0831f1a>] ip6_finish_output2+0xfa/0x350 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814caf3d>] ? csum_partial_copy_fromiovecend+0x18d/0x250
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0832208>] ip6_finish_output+0x98/0xc0 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa08322a8>] ip6_output+0x78/0xb0 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff81510e8d>] ? ip_generic_getfrag+0x3d/0xb0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0832329>] ip6_local_out+0x29/0x30 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa08325fa>] ip6_Push_pending_frames+0x2ca/0x450 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa0849ac8>] udp_v6_Push_pending_frames+0x168/0x410 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffffa084a7f5>] udpv6_sendmsg+0x7e5/0xc10 [ipv6]
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff81544d65>] inet_sendmsg+0x45/0xb0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814bd550>] sock_sendmsg+0xb0/0xe0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff8113c51e>] ? free_pages+0x3e/0x40
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff8115c042>] ? tlb_finish_mmu+0x32/0x50
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff8116353a>] ? unmap_region+0xea/0x110
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff814bd6d9>] sys_sendto+0x159/0x1c0
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff812a9a97>] ? __percpu_counter_add+0x67/0x80
Mar 9 13:36:35 atlassiandb100 kernel: [<ffffffff815aba8c>] system_call_fastpath+0x16/0x1b
Mar 9 13:36:35 atlassiandb100 kernel: ---[ end trace 3b257d5567b7ecd7 ]---
Mar 9 13:36:35 atlassiandb100 kernel: ------------[ cut here ]------------
Je reçois toujours ceci, plusieurs fois par seconde. Il ne semble pas s'agir d'un problème matériel (rien d'autre n'indique des problèmes matériels) et dès que Postgres est arrêté, les erreurs s'arrêtent.
Le message est à peu près exactement ce qui est dans le billet de blog que j'ai lié ci-dessus, c'est ainsi que je suis arrivé à la chose IPv6. Je suis juste très confus et frustré parce que même si je dis postgresql.conf pour écouter uniquement sur l'adresse IPv4, lsof -i6 me montre les processus Postgres liés à IPv6.
telnet est refusé sur les connexions IPv6:
telnet: connect to address ::1: Connection refused
J'ai également jeté un œil via netstat -a et je ne vois que l'écoute IPv4 via TCP et un flux UNIX.
Le démarrage mentionne un port mais je ne vois rien d'autre qui indiquerait IPv6:
postgres 37921 0.0 0.5 64539596 1441588 ? S Mar06 2:32
/usr/pgsql-9.3/bin/postmaster -p 5432 -D /var/lib/pgsql/9.3/data
Nous sommes corrigés pour Spectre et Meltdown, en cours d'exécution
kernel-uek-3.8.13-118.20.2.el6uek.x86_64
Je préfère ne pas désactiver complètement IPv6 dans le système d'exploitation, car nous maintenons des milliers de serveurs et souhaitons éviter les serveurs "flocon de neige" autant que possible. Si nous en avons besoin, nous emprunterons cette voie.
Merci à tous pour les suggestions. Je n'avais pas cliqué dans mon cerveau que les messages de trace étaient causés par des communications UDP. Cela m'a amené à ce billet de blog . Ce n'est pas exactement mon problème, mais cela m'a finalement conduit à la solution:
PostgreSQL utilise la fonction POSIX getaddrinfo (3) pour résoudre localhost.
Le test de la fonction getaddrinfo a prouvé qu'elle renvoyait ::1 avant son retour 127.0.0.1. J'ai fini par commenter la ligne IPv6 dans/etc/hosts et à redémarrer Postgres. Voila! Plus de messages de trace fous dans syslog.