<!DOCTYPE html> <html> <head> </head> <body> <p> </p> <p>Finally, the error went away after the db re-initializing. <br /><br />What I did was <br /><br />1) issued rm /var/log/reporting/rrd/* <br />2) issued /etc/init.d/syslogng restart <br />3) issued /etc/init.d/rrdcache restart <br /><br />… see another error about wrong time ("illegal attempt to update using time…") <br /><br />4) issued /etc/init.d/postgresql92 rebuild <br />5) issued /etc/init.d/syslogng restart <br />6) issued /etc/init.d/rrdcache restart <br />… no more errors 🙂 <br /><br />Nice side effect: <br /><br />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. <br />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. <br /><br />Could this be a performance Problem on the UTM due to the rrdcached error? <br /><br />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 <img src="https://community.sophos.com/emoticons/emotion-5.gif" alt="Wink" /> <br /><br />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, …) .</p> </body> </html>
Subscribe
0 Comments
Oldest