SG330 unresponsive for a couple of minutes with postgres[4267] error

Hi, Ilias, and welcome to the UTM Community!

If you're hesitant to move to V9.4 and you're not uncomfortable about losing existing data in Reporting and graphs, you can ask Sophos Support to rebuild your PostgreSQL data bases.  Then again, this is the first and only time this specific issue has been seen here.  I can just tell you that, in the past, similar issues were fixed with a rebuild.

Sachin, what about 9.4 should obviate this issue and, possibly, similar ones?

Cheers - Bob

Hi Balfson,

Yes, v9.4 should obviate this issue and possibly similar ones.

Thanks

Sachin Gurung

Hi Sachin,

I did update firmware (currently on version: 9.401-11) but I still have the same issue (although less frequently).

Any suggestions??

Hi Ilias,

Please provide me the log lines when you face the issue again?

Thanks

Hi Ilias,

Please provide me the log lines when you face the issue again?

Thanks

2016:05:05-13:30:01 vianexutm /usr/sbin/cron[23636]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2016:05:05-13:30:01 vianexutm /usr/sbin/cron[23637]: (root) CMD ( /usr/local/bin/rpmdb_backup )
2016:05:05-13:30:01 vianexutm /usr/sbin/cron[23638]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2016:05:05-13:32:01 vianexutm /usr/sbin/cron[23847]: (root) CMD (  nice -n19 /usr/local/bin/gen_inline_reporting_data.plx)
2016:05:05-13:35:01 vianexutm /usr/sbin/cron[23978]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2016:05:05-13:36:01 vianexutm /usr/sbin/cron[24074]: (root) CMD (/var/aua/update_ad_bg_members.plx)
2016:05:05-13:37:01 vianexutm /usr/sbin/cron[24134]: (root) CMD (/sbin/audld.plx --trigger)
2016:05:05-13:38:24 vianexutm postgres[24354]: [3-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:38:30 vianexutm postgres[4211]: [44-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:38:41 vianexutm postgres[4211]: [45-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:38:51 vianexutm postgres[4211]: [46-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:39:07 vianexutm postgres[4211]: [47-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:39:18 vianexutm postgres[4211]: [48-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:39:42 vianexutm postgres[4211]: [49-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:39:52 vianexutm postgres[4211]: [50-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:40:01 vianexutm /usr/sbin/cron[24797]: (root) CMD (/var/mdw/scripts/pmx-blocklist-update)
2016:05:05-13:40:01 vianexutm /usr/sbin/cron[24798]: (root) CMD (   /usr/local/bin/reporter/system-reporter.pl)
2016:05:05-13:40:02 vianexutm postgres[4211]: [51-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:40:19 vianexutm postgres[4211]: [52-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:40:29 vianexutm postgres[4211]: [53-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:40:39 vianexutm postgres[4211]: [54-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:40:56 vianexutm postgres[4211]: [55-1] LOG:  using stale statistics instead of current ones because stats collector is not responding
2016:05:05-13:44:17 vianexutm dns-resolver[4781]: Changeset 202 empty!
2016:05:05-13:44:17 vianexutm dns-resolver[4781]: Adding REF_DefaultSophosUTMSupportHost
2016:05:05-13:44:17 vianexutm dns-resolver[4781]: Adding REF_NetDnsSophoLivec
2016:05:05-13:44:17 vianexutm dns-resolver[4781]: Adding REF_NtpPool
2016:05:05-13:44:17 vianexutm dns-resolver[4781]: No change to REF_DefaultSophosUTMSupportHost :: dispatch.apu.sophos.com
2016:05:05-13:44:17 vianexutm dns-resolver[4781]: Updating REF_NtpPool :: pool.ntp.org
2016:05:05-13:44:18 vianexutm ntpd[29624]: ntpd exiting on signal 15 (Terminated)
2016:05:05-13:44:18 vianexutm ntpd[29624]: 127.127.1.0 local addr 127.0.0.1 -> <null>
2016:05:05-13:44:18 vianexutm ntpd[29624]: 194.177.210.54 local addr 195.167.62.101 -> <null>
2016:05:05-13:44:18 vianexutm ntpd[29624]: 79.107.99.220 local addr 195.167.62.101 -> <null>
2016:05:05-13:44:18 vianexutm ntpd[25169]: ntpd 4.2.8p4@1.3265-o Mon Jan 18 21:44:29 UTC 2016 (1): Starting
2016:05:05-13:44:18 vianexutm ntpd[25169]: Command line: /sbin/ntpd
2016:05:05-13:44:18 vianexutm ntpd[25171]: proto: precision = 0.312 usec (-22)
2016:05:05-13:44:18 vianexutm ntpd[25171]: restrict 0.0.0.0: KOD does nothing without LIMITED.
2016:05:05-13:44:18 vianexutm ntpd[25171]: restrict ::: KOD does nothing without LIMITED.
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen and drop on 0 v6wildcard [::]:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen and drop on 1 v4wildcard 0.0.0.0:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen normally on 2 lo 127.0.0.1:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen normally on 3 eth0 10.20.60.24:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen normally on 4 eth1 195.167.62.101:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen normally on 5 eth2 192.168.66.5:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen normally on 6 tun0 10.242.2.1:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listen normally on 7 lo [::1]:123
2016:05:05-13:44:18 vianexutm ntpd[25171]: Listening on routing socket on fd #24 for interface updates
2016:05:05-13:45:01 vianexutm /usr/sbin/cron[25229]: (root) CMD ( /usr/local/bin/rpmdb_backup )

Hi,

When you monitored these log lines, was SG unresponsive ?

Thanks

The common attitude is the following:

First I notice the web protection unresponsiveness (no web page is loading).

I log on to the UTM and i see 4-5 lines of "LOG:  using stale statistics instead of current ones because stats collector is not responding" in the system log.

A few minutes later the whole UTM becomes unresponsive for a couple of minutes (the WEB UI halts as well).

Then everything comes back to normal as if a fast reboot took place.

Have you tried the Up2Date and the database rebuild suggested above?

Cheers - Bob

Yes, I have updated the firmware to 9.4 and since then I see this error quite rarely (however it still happens).

No, I didn't rebuild PostgreSQL. Will this fix my problem without mess around with my UTM config (This is our production UTM)? I' ll need some guidance if that is the case.

The following command will reset the databases in reporting and the graphs in reporting. It will not affect the log files.  I can't be certain that it will fix your problem.

   /etc/init.d/postgresql92 rebuild

Cheers - Bob

OK, so I did execute the postgres rebuild command but did not solve my problem.

Ilias, you need to be insistent that Sophos Support address this issue.  Please let us know what the problem was and how they fixed it.

Cheers - Bob

The issue was fixed after updating to v. 9.403-4.

Cheers!

Update: I am running the last few months with the same issue. It just happens more rare and for short period of time. My thought is that this db unresponsiveness is more like a performance issue rather than a db error.