Help us enhance your Sophos Community experience. Share your thoughts in our Sophos Community survey.

Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 20509 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

[Solved]UTM problems with rrdcached since 9.315-2

cwoller
Hi. 

Since the update to 9.315-2, the UTM 320 is slow on speed and we got tons of erros from rrdcached. The "Fallback" log fills up with messages like this:

2015:08:18-08:43:44 han-e7-secapp [daemon:notice] rrdcached[10060]: queue_thread_main: rrd_update_r (/var/log/reporting/rrd/apusage_A400175F685D801.rrd) failed with status -1. (/var/log/reporting/rrd/apusage_A400175F685D801.rrd: illegal attempt to update using time 1439323024 when last update time is 1439323085 (minimum one second step))

and this

2015:08:18-08:44:19 han-e7-secapp [daemon:info] rrdcached[10124]: starting up
2015:08:18-08:44:19 han-e7-secapp [daemon:info] rrdcached[10124]: checking for journal files
2015:08:18-08:44:19 han-e7-secapp [daemon:notice] rrdcached[10124]: replaying from journal: /var/log/reporting/rrd/rrd.journal.1439316807.508822

Every hour we get emails with this subject:

[INFO-192] RRD cache daemon not running - restarted

Has anybody seen this before or has any hit to solve this? 

I tried google on this but it seams to me, that his error is a kind of special on our system.

Any hint is welcome.

Best regards, Christian


This thread was automatically locked due to age.
Parents
  • 0
    Christian, Do you think the problem had been solved by the second step, re-initializing the data bases behind the graphs?  Or, was it not solved until the last command using rebuild?

    Cheers - Bob
    PS Changed the title.
     
    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
    Christian, Do you think the problem had been solved by the second step, re-initializing the data bases behind the graphs?  Or, was it not solved until the last command using rebuild?

    Cheers - Bob
    PS Changed the title.


    Hi Bob.

    As I said, I am not an UTM expert but if I should make a guess, it was the combination of cleaning the rrd folder with re-initializing the db. 

    Finally, the error went away after the db re-initializing. 

    What I did was

    1) issued rm /var/log/reporting/rrd/*
    2) issued /etc/init.d/syslogng restart
    3) issued /etc/init.d/rrdcache restart

    ... see another error about wrong time ("illegal attempt to update using time...")

    4) issued /etc/init.d/postgresql92 rebuild
    5) issued /etc/init.d/syslogng restart
    6) issued /etc/init.d/rrdcache restart
    ... no more errors :-)

    Nice side effect:

    Some users told me yesterday, that while the rrdcached problem occurs, they had some "Proxy does not respond" errors within their browsers while surfing the web. I've seen this in my browser too but couldnt reproduce it. The proxy error came at random and went away after pressing the "reload" button.

    Could this be a performance Problem on the UTM due to the rrdcached error? 

    I mean, I had a fallback log size growth of 6-7 GB/day and I could imagine that the UTM 320 had something else to do than deliver data to the internal network [;)]

    Now, after the rrdcached problem, I havent seen the proxy errors anymore, and the whole UTM is much more responsive (WebAdmin, throughput while surfing the Web, ...) .

    Best regards,

    Christian
Reply
  • 0 in reply to BAlfson
    Christian, Do you think the problem had been solved by the second step, re-initializing the data bases behind the graphs?  Or, was it not solved until the last command using rebuild?

    Cheers - Bob
    PS Changed the title.


    Hi Bob.

    As I said, I am not an UTM expert but if I should make a guess, it was the combination of cleaning the rrd folder with re-initializing the db. 

    Finally, the error went away after the db re-initializing. 

    What I did was

    1) issued rm /var/log/reporting/rrd/*
    2) issued /etc/init.d/syslogng restart
    3) issued /etc/init.d/rrdcache restart

    ... see another error about wrong time ("illegal attempt to update using time...")

    4) issued /etc/init.d/postgresql92 rebuild
    5) issued /etc/init.d/syslogng restart
    6) issued /etc/init.d/rrdcache restart
    ... no more errors :-)

    Nice side effect:

    Some users told me yesterday, that while the rrdcached problem occurs, they had some "Proxy does not respond" errors within their browsers while surfing the web. I've seen this in my browser too but couldnt reproduce it. The proxy error came at random and went away after pressing the "reload" button.

    Could this be a performance Problem on the UTM due to the rrdcached error? 

    I mean, I had a fallback log size growth of 6-7 GB/day and I could imagine that the UTM 320 had something else to do than deliver data to the internal network [;)]

    Now, after the rrdcached problem, I havent seen the proxy errors anymore, and the whole UTM is much more responsive (WebAdmin, throughput while surfing the Web, ...) .

    Best regards,

    Christian
Children
No Data
Unfiltered HTML