如何禁用 Postgres 侦听 IPv6？

Question

由于一堆奇怪的跟踪文件不断写入系统日志，我试图禁用 Postgres 侦听 IPv6。

我不想在操作系统本身中禁用 IPv6，因此在看到提及跟踪消息并找到博客文章Disable IPv6 Postgres 和 PGBouncer 后，我已按照第 2 步进行更新postgresql.conf（将“*”更改为“0.0.0.0 ”）：

# grep listen postgresql.conf
listen_addresses = '0.0.0.0'

我也在里面找到了这个条目pg_hba.conf并注释掉了它：

# IPv6 local connections:
#host    all             all             ::1/128                 trust

我重新启动了 Postgres。netstat似乎表明它不再监听 IPv6：

# netstat -ntl | grep 5432
tcp        0      0 0.0.0.0:5432                0.0.0.0:*                   LISTEN

似乎lsof有不同的想法：

# 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>

这可能是一个错误吗？还是我在这里遗漏了一些明显的东西？

系统为：
Oracle Linux 6.9
Kernel 3.8.13-118.20.2.el6uek.x86_64
PostgreSQL 9.3.21

跟踪文件来自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 ]------------

我仍然收到这个，每秒几次。它似乎不是硬件问题（没有其他迹象表明硬件问题），一旦 Postgres 停止，错误就会停止。

该消息几乎与我上面链接的博客文章中的内容完全相同，这就是我如何到达 IPv6 事物的方式。我只是非常困惑和沮丧，因为即使我告诉我postgresql.conf只听 IPv4 地址lsof -i6，也会向我展示绑定到 IPv6 的 Postgres 进程。

telnet 在 IPv6 连接上被拒绝：

telnet: connect to address ::1: Connection refused

我还查看了通过netstat -a，我只看到 IPv4 通过 TCP 和 unix STREAM 进行侦听。

启动确实提到了一个端口，但我没有看到任何其他表明 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

我们为 Spectre 和 Meltdown 打了补丁，运行

kernel-uek-3.8.13-118.20.2.el6uek.x86_64

我不想在操作系统中完全禁用 IPv6，因为我们维护着数千台服务器，并希望尽可能避免“雪花”服务器。如果需要，我们会走那条路。

Answer 1

谢谢大家的建议。我没有想到跟踪消息是由 UDP 通信引起的。这让我看到了这篇博文。这不完全是我的问题，但它最终使我找到了解决方案：

PostgreSQL 使用 POSIX 函数 getaddrinfo(3) 来解析 localhost。

测试 getaddrinfo 函数证明它在返回::1之前就返回了127.0.0.1。我最终注释掉了 /etc/hosts 中的 IPv6 行并重新启动了 Postgres。瞧！系统日志中不再有疯狂的跟踪消息。