Curious UDP packets
Hello. There are messages like this in shorewall's logs. x.x.x.x is
my site's IP address, both as the source and the destination. I've
been told that they're caused by postgresql. Having these messages
filtered out doesn't seem to affect postgresql in any way. Does
anyone know why postgresql would want to talk to itself in this way?
I'm using postgresql 7.4.7. My guess would be that this is some sort
of a heartbeat.
omega kernel: Shorewall:all2all:REJECT:IN= OUT=lo
SRC=x.x.x.x DST=x.x.x.x LEN=1016 TOS=0x00 PREC=0x00
TTL=64 ID=21629 DF PROTO=UDP SPT=32769 DPT=32769 LEN=996
Hello. There are messages like this in shorewall's logs.
x.x.x.x is my site's IP address, both as the source and the
destination. I've been told that they're caused by
postgresql. Having these messages filtered out doesn't seem
to affect postgresql in any way. Does anyone know why
postgresql would want to talk to itself in this way?
I'm using postgresql 7.4.7. My guess would be that this is
some sort of a heartbeat.omega kernel: Shorewall:all2all:REJECT:IN= OUT=lo SRC=x.x.x.x
DST=x.x.x.x LEN=1016 TOS=0x00 PREC=0x00
TTL=64 ID=21629 DF PROTO=UDP SPT=32769 DPT=32769 LEN=996
The PostgreSQL stats collector uses UDP over a random loopback port. It
should normally use localhost, though and not a "real" IP.
To see if that's it, turn of the stats collector
(start_stats_collector=off), restart postgresql (restart needed ,not
enough to just HUP) and see if they go away.
Another way might be to see if the pg_stat_activity view is empty
(select * from pg_stat_activity). With the stats collector running it
should never be empty - it should contain at least your own process -
but if the stats packets don't get through that's what would happen.
//Magnus
Import Notes
Resolved by subject fallback
On Fri, Apr 14, 2006 at 02:59:10PM +0200, Magnus Hagander wrote:
omega kernel: Shorewall:all2all:REJECT:IN= OUT=lo SRC=x.x.x.x
DST=x.x.x.x LEN=1016 TOS=0x00 PREC=0x00
TTL=64 ID=21629 DF PROTO=UDP SPT=32769 DPT=32769 LEN=996The PostgreSQL stats collector uses UDP over a random loopback port. It
should normally use localhost, though and not a "real" IP.
It's a virtual server, that (currently) has no loopback device.
Is it possible to tell the stats collector to use a specific port?
To see if that's it, turn of the stats collector
(start_stats_collector=off), restart postgresql (restart needed ,not
enough to just HUP) and see if they go away.
Apparently this didn't prevent those UDP packets... I'm not certain
about this one, though, since I wasn't the one testing this.
omega kernel: Shorewall:all2all:REJECT:IN= OUT=lo SRC=x.x.x.x
DST=x.x.x.x LEN=1016 TOS=0x00 PREC=0x00
TTL=64 ID=21629 DF PROTO=UDP SPT=32769 DPT=32769 LEN=996The PostgreSQL stats collector uses UDP over a random
loopback port.
It should normally use localhost, though and not a "real" IP.
It's a virtual server, that (currently) has no loopback device.
Aha. That explains it.
Is it possible to tell the stats collector to use a specific port?
No.
To see if that's it, turn of the stats collector
(start_stats_collector=off), restart postgresql (restartneeded ,not
enough to just HUP) and see if they go away.
Apparently this didn't prevent those UDP packets... I'm not
certain about this one, though, since I wasn't the one testing this.
That sounds strange - if it was the stats collector, it shuodl be gone.
Verify by running "ps axuwf" (or such) to see if there are two processes
named "stats collector" and "stats bufferer" running. If they are, you
failed to turn them off :-)
If not, it's some other process, try something like "netstat -nap" to
figure out which process is listening for them.
//Magnus
Import Notes
Resolved by subject fallback