PostgresがIPv6でリッスンするのを無効にする方法は？
常にsyslogに書き込まれている奇妙なトレースファイルがたくさんあるので、PostgresがIPv6でリッスンできないようにしようとしています。
OS自体で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
カーネル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に到達した方法です。 IPv4アドレスのみをリッスンするようにpostgresql.confに指示しても、lsof -i6はIPv6にバインドされているPostgresプロセスを表示するので、私は非常に混乱してイライラしています。
telnetはIPv6接続では拒否されます：
telnet: connect to address ::1: Connection refused
また、netstat -aを介して確認し、TCPおよびUNIXストリームを介してIPv4リスニングを確認しました。
スタートアップはポートについて言及していますが、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
私たちは何千ものサーバーを維持していて、できる限り「スノーフレーク」サーバーを避けたいので、OSでIPv6を完全に無効にしたくありません。必要な場合は、そのルートを使用します。
みんなの提案をありがとう。トレースメッセージがUDP通信によって引き起こされたことが私の脳内でクリックされていませんでした。それが このブログ投稿 につながりました。それは正確ではありません私の問題ではありませんが、最終的に解決策に導いた：
PostgreSQLは、POSIX関数getaddrinfo（3）を使用してlocalhostを解決します。
Getaddrinfo関数をテストすると、::1戻る前に127.0.0.1。/etc/hostsのIPv6行をコメントアウトして、Postgresを再起動しました。出来上がり！ syslogにクレイジーなトレースメッセージはもうありません。