Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 15 replies
  • Subscribers 6 subscribers
  • Views 32693 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

IliasTsoukalis

Randomly during the day I might get this error:

"postgres[4267]: [10-1] LOG: using stale statistics instead of current ones because stats collector is not responding"

for a few minutes.

The my UTM becomes unresponsive for one minute or so and then i comes back to life.


The UTM is the SG330 with 9.355-1 firmware.

The CPU or memory load is low in general or during those errors. I cannot find any rational reason why this happens. Seems like a db bug to me.

Thanks!



This thread was automatically locked due to age.
  • 0

    Hi Ilias,

    Greetings.

    We had a reported bug with the log line "using stale statistics instead of current ones because stats collector is not responding". But the related issue with this log line was, Postgres shutting down and causing email and wireless outage.

    This Bug is resolved in v9.400. I request you to upgrade your UTM.

    Hope that helps:)

    Thanks

    Sachin Gurung

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0

    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

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    Hi Balfson,

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

    Thanks

    Sachin Gurung

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0 in reply to sachingurung

    Hi Sachin,


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


    Any suggestions??

  • 0 in reply to IliasTsoukalis

    Hi Ilias,

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

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0 in reply to sachingurung

    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 )

  • 0 in reply to IliasTsoukalis

    Hi,

    When you monitored these log lines, was SG unresponsive ?

    Thanks

    Sachin Gurung
    Team Lead | Sophos Technical Support
    Knowledge Base  |  @SophosSupport  |  Video tutorials
    Remember to like a post.  If a post (on a question thread) solves your question use the 'This helped me' link.

  • 0 in reply to sachingurung

    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.

  • 0 in reply to IliasTsoukalis

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

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson

    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.

Unfiltered HTML