Guest User!

You are not Sophos Staff.

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

Data Disk is filling up - please check. Current usage: 83%

A client of ours have two ASG220s in a HA cluster active active. Just recently they have been getting email notifications saying the following ...

-- 
HA Status          : CLUSTER SLAVE (node id: 2)
System Uptime      : 10 days 20 hours 57 minutes
System Load        : 0.11
System Version     : Astaro Security Gateway 7.202

Please refer to the manual for detailed instructions.

Logged onto the ASG and the dashboard shows
CPU 13%
RAM 84%
SWAP 15%
Log disk 1%
Data Disk 3%

Logged onto the ASG at the command line via ssh
Master Node1 /var/storage 3% used
Slave Node2 /var/storage 86% used

There is 22GB in /var/storage/chroot-http/tmp.

In the short term can I delete these files?

The official reply from ASG support is to perform a "Factory Reset" on the slave. This is the second time this happened now.

We have other clients that also have HA cluster active active - ASG220 / ASG320s etc with no such issues.

Anyone else out there had any similar problems?


This thread was automatically locked due to age.
Parents
  • I'm getting these messages today for the first time myself.  Not sure what to do...
  • you will need to identify what node the message relates to. Then logon at the command promt using ssh to loginuser and su to root.

    To find what is taking the space type

    df -h

    Now compare this on the other node.

    I deleted the files that were taking up the space - log files mainly. Not too important. then carried out a factory reset at the ASG front panel. this did resolve the issue.

    But I have a feeling it will happen again! I am will monitor theis ASG cluster close indeed.
  • I don't have several of those files/folders on our 7.306 install; I'm guessing they're leftover from old versions and can be deleted...

    e.g. squid is from v6; mysql is from older 7.x, and I don't think that 16gb meminfo file is needed.

    Make a backup, and start deleting [:)]
    e.g. 
    rm meminfo
    rm -r mysql

    How big is your hard disk?

    Barry
  • dashboard says 72% of 27GB used....

    I'm really not comfortable with deleting stuff. When I lose the configuration all log data and quarantine and everything is lost right?
    Really don't want this to happen... Is there a way to backup that stuff?
  • I'm pretty sure the folders I mentioned are leftover from older versions; e.g. Squid and MySQL are no longer used in 7.306.
    I don't have that large file either, it's probably safe to delete, but maybe someone else can confirm.

    FYI, Squid hasn't been used since Astaro 6.x.

    Barry
  • Actually, I think they used Squid up until version 7.100 ...
  • alright. After asking our unix/linux expert to look into this we figured out there must have been some kind of debugging going on.
    The meminfo file was beeing filled by a cronjob task every minute. This started when we had an astaro support guy looking into our appliance, when we had another problem that was solved by now. My guess is: he must have forgotten to turn of the task. So now we commented out the job, renamed the file and will see if it still keeps coming back or not. When that doesn't happen and everything works fine we'll delete it and have 16gigs of space left.

    problem solved [:)] Thanks for the advice guys.
  • Right.  That was why I suggested a reboot.
  • that wouldn't have helped... we rebooted a couple of times between then and now. It just kept adding and adding text to the file because the cronjob kept running - even after the reboot it just added a line every minute...
  • Thanks for confirming that.

    I bet the Astaro support guy is embarrassed!

    Cheers - Bob
  • Commenting out the cronjob is not a permanent solution. The crontab is dynamically created, and a change of the configuration might lead to a re-write of the crontab. 

    When the crontab is dynamically re-created, all files named /etc/crontab.whatever are considered static, permanent jobs and merged together in the final /etc/crontab file, so I'd suggest you check if there is a crontab.something file existing that contains the command you want to remove, and remove that file, too.

    Cheers,
     andreas
  • Doesn't seem as if there's anything left. Just checked the files.
    Will let you know if anything happens though.
Reply Children
No Data