Thread Info
  • State Not Answered
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 7 replies
  • Subscribers 7 subscribers
  • Views 19167 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

Log Disk is filling up <Solved?>

RodHunt
Please advise. 

I've searched for a solution within the posts but /var/log/reporting/pgsql/16550 keeps going over 5G. 

I am on version 8.103 running on a ESXi VM. Been running Astaro in this way for several years.

I have tried:

1) Rebooting: too many times to count. 

2) Flushing HTTP cache

3) Deleting all content in /var/log/reporting/pgsql/16550 which reduces /var/log to 3% full. postgres just recreates 5G of files on reboot bring me back up to 94% full.

4) Dropping report retention to 7 days, 3 weeks, 3 month.

And as a last attempt while writing this post I

5) Deleting all content in /var/log/reporting/pgsql/16550 which reduces /var/log to 3% full. Reboot and it held at 3%. 

Of course I don't know if I broke something.....

Thank you for your help.


This thread was automatically locked due to age.
Parents
  • 0

    Part of your reporting database has crashed/become corrupted is the reason for the problem.  By manually deleting the files, you will have broken some part of reporting.

    Log into the shell as root (or loginuser, then SU), then you'll need to run the following commands to get everything fixed, with each line being run separately.

    /etc/init.d/postgresql stop
    rm -fr /var/log/reporting/pgsql
    /etc/init.d/postgresql start
    mkdir /var/log/reporting/pgsql
    chown postgres[:P]ostgres /var/log/reporting/pgsql
    /var/storage/pgsql/init/reporting_db_init.sh -v



    [BAlfson]In a post on 2012-05-09, Scott informed us:

    It's even easier now.  Just a single command:

    /etc/init.d/postgresql rebuild

    [BAlfson 2016-08-24] Several years ago, the command became

     /etc/init.d/postgresql92 rebuild

    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
Reply
  • 0

    Part of your reporting database has crashed/become corrupted is the reason for the problem.  By manually deleting the files, you will have broken some part of reporting.

    Log into the shell as root (or loginuser, then SU), then you'll need to run the following commands to get everything fixed, with each line being run separately.

    /etc/init.d/postgresql stop
    rm -fr /var/log/reporting/pgsql
    /etc/init.d/postgresql start
    mkdir /var/log/reporting/pgsql
    chown postgres[:P]ostgres /var/log/reporting/pgsql
    /var/storage/pgsql/init/reporting_db_init.sh -v



    [BAlfson]In a post on 2012-05-09, Scott informed us:

    It's even easier now.  Just a single command:

    /etc/init.d/postgresql rebuild

    [BAlfson 2016-08-24] Several years ago, the command became

     /etc/init.d/postgresql92 rebuild

    __________________
    ACE v8/SCA v9.3

    ...still have a v5 install disk in a box somewhere.

    http://xkcd.com
    http://www.tedgoff.com/mb
    http://www.projectcartoon.com/cartoon/1
Children
  • 0 in reply to Scott_Klassen

    Uh, guys...is this still valid? Seems I am missing something. I have a postgresql92 available, and tried this postgresql92 rebuild and then prompted for password which is not root password.


    The data is filling up even after clearing logs, which I understand is not going to happen until next maintenance cycle? Just curious if this is supposed to still work with UTM 230 and 9.405-5

    Thanks,

    joel

  • 0 in reply to Scott_Klassen

    I am currently having same issue. However, I don't seem to have proper permissions as roob to rebuild or access some locations. Please advise.

  • 0 in reply to AZSysAdmin

    I have not yet needed to do this on a unit with 9.405, so I don't know if the behavior has changed.  You should be running the command as root.  I've not ever been asked for a password when doing that - and I've never tried when not.

    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

    Thanks, Bob. Running 9.405 I am seeing the logs grow. I was not able to see the exact log as you have asked others. I believe the changes to Webserver Protect were the issue. However, a clearing of logs and reboot cleared up the issue and disk consumption is back down to 5%.

  • 0 in reply to AZSysAdmin

    Hi AZ,

    Do you mean you did manually remove the files at /var/storage/pgsql92/data/pg_xlogs? from what I hear it is not advisable to remove these files manually!!

    we are face the same issue.

    Thanks

  • 0 in reply to AreshAreshi

    AreshAreshi,

    NO! I did not manually remove these files. It is my understanding that removing files would cause more problems. I used the SSH command to rebuild, and then rebooted and since log files have not been a issue. I followed a suggestion by BAlfson to look into the largest of log files and found that the WebServer Protection log seemed to be it (guess). 

    Again, no I did NOT delete or remove files. I changed the length of time in which log files were retained, which did not clean up after the 24 hour period. Then I SSH'd and looked into the log files, checking which were largest and looking at each log to see if any specific errors. I did not see anything that specifically read ERROR, so I sent the rebuild command to /etc/init.d/postgresgl92 rebuild and then restarted hours later and the logs cleared. Its been about a week and not seeing any further issue. We're at 9% and holding.

    Hope this helps!

Unfiltered HTML