[9.065][BUG] Wrong graphs after data partition filled

Hey Bill,

The information displayed in the "bubble" is associated with the instant values for storage/log/root (the dots on the graph). As far as i can see the storage right now is empty. Did you maybe empty your disk? I'm asking this because the figures for storage (blue), suddenly decreased to 0. Can you please run the "df" command and see the % that is in use?
In addition to this, in second graph the max and min values are reversed. That is for sure a bug [:)]
Looking forward for your feedback. Cheers,

Hi Bianca, if you look at the graphs, the storage partition was at 100 percent till it went to zero all of a sudden close to midnight. I did not make any changes to the system at the time but it seems that after the database rollover at midnight, the graphing system had a glitch.

...As far as i can see the storage right now is empty. Did you maybe empty your disk? I'm asking this because the figures for storage (blue), suddenly decreased to 0. Can you please run the "df" command and see the % that is in use?

Sorry, I have since rolled my system back due to the space problems but keep in mind that the storage partition is never zero. I have never tried it but so many daemons use storage partition that it would almost be impossible to completely delete the contents without a useless system.

I did take a final partition reading after deleting some files from the storage partition in the link https://community.sophos.com/products/unified-threat-management/astaroorg/f/80/t/64883 But this was done many hours later due to my http proxy and smtp being useless and thats when I noticed the graphing problem before a system reset.

I will repost them here for better thread management.

gatekeeper:/var/storage/pgsql92/data/pg_xlog # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       5.3G  1.9G  3.2G  37% /
udev           1014M   76K 1014M   1% /dev
tmpfs          1014M     0 1014M   0% /dev/shm
/dev/sda1       339M   21M  302M   7% /boot
/dev/sda5       4.7G  895M  3.6G  20% /var/storage
/dev/sda7       6.2G  240M  5.6G   5% /var/log
/dev/sda8       713M   28M  649M   5% /tmp
tmpfs          1014M   52K 1014M   1% /var/storage/chroot-smtp/tmp/ram
tmpfs          1014M  4.9M 1009M   1% /var/storage/chroot-http/tmp

Regards
Bill

Hi Bianca, if you look at the graphs, the storage partition was at 100 percent till it went to zero all of a sudden close to midnight. I did not make any changes to the system at the time but it seems that after the database rollover at midnight, the graphing system had a glitch.

...As far as i can see the storage right now is empty. Did you maybe empty your disk? I'm asking this because the figures for storage (blue), suddenly decreased to 0. Can you please run the "df" command and see the % that is in use?

Sorry, I have since rolled my system back due to the space problems but keep in mind that the storage partition is never zero. I have never tried it but so many daemons use storage partition that it would almost be impossible to completely delete the contents without a useless system.

I did take a final partition reading after deleting some files from the storage partition in the link https://community.sophos.com/products/unified-threat-management/astaroorg/f/80/t/64883 But this was done many hours later due to my http proxy and smtp being useless and thats when I noticed the graphing problem before a system reset.

I will repost them here for better thread management.

gatekeeper:/var/storage/pgsql92/data/pg_xlog # df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda6       5.3G  1.9G  3.2G  37% /
udev           1014M   76K 1014M   1% /dev
tmpfs          1014M     0 1014M   0% /dev/shm
/dev/sda1       339M   21M  302M   7% /boot
/dev/sda5       4.7G  895M  3.6G  20% /var/storage
/dev/sda7       6.2G  240M  5.6G   5% /var/log
/dev/sda8       713M   28M  649M   5% /tmp
tmpfs          1014M   52K 1014M   1% /var/storage/chroot-smtp/tmp/ram
tmpfs          1014M  4.9M 1009M   1% /var/storage/chroot-http/tmp

Regards
Bill

Hi Bill,

I reproduced this issue on my machine. [:)]
Thanks for finding this one since got another 2 small bugs related to it.

Cheers,