Thread: Can't restart statistics collection and autovacuum

Hi Guys.
Yesterday, the database server was rebooted and database wasn't shut down properly.
When it went back online, the following messages showed up:
2014-03-13 08:46:08 UTC   LOG:  08006: test message did not get through on socket for statistics collector
2014-03-13 08:46:08 UTC   LOCATION:  pgstat_init, pgstat.c:463
2014-03-13 08:46:08 UTC   LOG:  00000: disabling statistics collector for lack of working socket
2014-03-13 08:46:08 UTC   LOCATION:  pgstat_init, pgstat.c:521
2014-03-13 08:46:08 UTC   WARNING:  01000: autovacuum not started because of misconfiguration
2014-03-13 08:46:08 UTC   HINT:  Enable the "track_counts" option.
2014-03-13 08:46:08 UTC   LOCATION:  autovac_init, autovacuum.c:2809
2014-03-13 08:46:08 UTC   LOG:  00000: database system was interrupted; last known up at 2014-03-13 08:41:49 UTC

I enabled the track_counts option, but when I checked it, it still shows as "off".
I have 2 questions:
1. Any ideas how to fix this? I've googled it and check this list and tried everything so far with no results.
2. Any link to a script I may post on rc6.d to avoid this mishap in the future?

PostgreSQL version is 9.1.3
OS:  Ubuntu 11.10 (GNU/Linux 3.0.0-12-virtual x86_64)

Ignacio Colmenero
Database Analyst
Abra Controls Inc.
P# (403) 775-2237
ignacio.colmenero@abracontrols.com

Ignacio Colmenero <ignacio.colmenero@abracontrols.com> writes:
> Yesterday, the database server was rebooted and database wasn't shut
> down properly.
> When it went back online, the following messages showed up:
> 2014-03-13 08:46:08 UTC   LOG:  08006: test message did not get through
> on socket for statistics collector

The only known reason for that to happen is kernel packet filtering rules
that prevent passing traffic through the stats-collector socket.  It seems
very unlikely that this "just happened" without somebody/something outside
Postgres actively breaking it.  I'd take a close look at recent system
configuration changes, particularly in the firewall area.  It wouldn't
hurt to know exactly *why* the system was rebooted, too.

            regards, tom lane

Thanks Tom.
The database had been up for 6 months now with no problems at all so, according to your comment, it was a change that became current when the server was rebooted. I need someone to help me out with the server rules to find out what's wrong (or different) with that.
Regarding the server reboot, our server is hosted by Rackspace and, for some reason it ran out of memory, and they rebooted it; that's something I also need to check out, but that's for another post.

Thanks.

Ignacio Colmenero <ignacio.colmenero@abracontrols.com> writes:

Yesterday, the database server was rebooted and database wasn't shut 
down properly.
When it went back online, the following messages showed up:
2014-03-13 08:46:08 UTC   LOG:  08006: test message did not get through 
on socket for statistics collector

The only known reason for that to happen is kernel packet filtering rules
that prevent passing traffic through the stats-collector socket.  It seems
very unlikely that this "just happened" without somebody/something outside
Postgres actively breaking it.  I'd take a close look at recent system
configuration changes, particularly in the firewall area.  It wouldn't
hurt to know exactly *why* the system was rebooted, too.
		regards, tom lane

Ignacio Colmenero
Database Analyst
Abra Controls Inc.
P# (403) 775-2237
ignacio.colmenero@abracontrols.com