Thread: 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
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=996 > > The 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=996 > > > > The 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 (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. 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