如何禁用 Postgres 監聽 IPv6？

由於一堆奇怪的跟踪文件不斷被寫入系統日誌，我試圖禁用 Postgres 監聽 IPv6。

我不想在作業系統本身中禁用 IPv6，所以在看到提到跟踪消息並找到部落格文章Disable IPv6 Postgres and 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，我只看到通過 TCP 和 unix STREAM 偵聽的 IPv4。

Startup 確實提到了一個埠，但我沒有看到任何其他表明 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，因為我們維護著數千台伺服器並希望盡可能避免“雪花”伺服器。如果需要，我們會走那條路。

謝謝大家的建議。我的大腦並沒有意識到跟踪消息是由 UDP 通信引起的。這導致了我這篇博文。這不完全是我的問題，但它最終讓我找到了解決方案：

PostgreSQL 使用 POSIX 函式 getaddrinfo(3) 來解析 localhost。

測試 getaddrinfo 函式證明它在返回::1之前已經返回127.0.0.1。我最終註釋掉 /etc/hosts 中的 IPv6 行並重新啟動 Postgres。瞧！syslog 中不再有瘋狂的跟踪消息。

引用自：https://dba.stackexchange.com/questions/199823