[7.400] Log Partition Status shows incorrect size

Not a bug. The sizes are stored in a Round-Robin Database (RRD). If you change the partition size manually, these entries make no sense anymore.

So, should he re-init the rrd data?

Barry

Well, I wouldn't call this a bug either since we never designed the system to work correctly if you manually change the partition structure. The graph probably got b0rked during the partition change which lead to an incorrect (and incredibly high) value entered into the RRD archive. The easiest solution for this would be to delete the RRD file /var/log/reporting/rrd/diskstat.rrd, it will be re-created again automatically. I take it the daily graph does work again, if so the alternative would be to wait until the time when this happened moves out of the scope of the respective graph (i.e., one week for the weekly, one month for the monthly, one year for the yearly).

Cheers,
 andreas

Not the graph field is wrong, /dev/sdb1 mounted on /var/log has 1TB storage... [8-)]

DarkServant

OK, then you're probably the first who reached a new hardware limit [:P]
Can you please post the contents of  '/etc/sysmond.ph' ? The 

'Internal:[:D]iskUsage' => { 

...

}

 section would be sufficient, thank you [:)]
Cheers,
 andreas

Hi there,
here is the content you have requested:

'Internal:[:D]iskUsage' => {

                                     '/' => {

                                              'blocks_avail' => 3769880,

                                              'blocks_total' => 5542276,

                                              'blocks_usage' => 28,

                                              'est_blocksfullin' => '41824105',

                                              'est_blockspersec' => '0.09',

                                              'inodes_avail' => 662416,

                                              'inodes_total' => 704512,

                                              'inodes_usage' => 6

                                            },

                                     '/var/log' => {

                                                     'blocks_avail' => 912374860,

                                                     'blocks_total' => 961432072,

                                                     'blocks_usage' => 0,

                                                     'est_blocksfullin' => '110811054',

                                                     'est_blockspersec' => '8.23',

                                                     'inodes_avail' => 122108121,

                                                     'inodes_total' => 122109952,

                                                     'inodes_usage' => 0

                                                   },

                                     '/var/storage' => {

                                                         'blocks_avail' => 255622264,

                                                         'blocks_total' => 270021528,

                                                         'blocks_usage' => 0,

                                                         'est_blocksfullin' => '156113038',

                                                         'est_blockspersec' => '1.64',

                                                         'inodes_avail' => 69686567,

                                                         'inodes_total' => 69697536,

                                                         'inodes_usage' => 0

                                                       }

DarkServant

Thanks,
the data looks fine. I'm at a loss now, actually - the data is completely OK, but the picture does not correspond to the data. I injected your data into my test machine, and on that machine the WebAdmin page looks OK, too. 
I guess I need to mull over this for a while. Is the value shown in the Webadmin for log partition size and free space changing or is it always the same?

Cheers,
 andreas

Here is a picture of the Main Site and the Logging Site from the Webadmin GUI:

OK, after mulling over things and following code paths from a to z things now became clear. Those two webadmin pages use the identical data in the backend, there's just one more step in between when computing the data for the Logging page which seems to be broken on your machine. Can you please check out the timestamps for the files in '/var/log/reporting/inline/' ? I'd assume that the timestamp for at least the logging.ph file did not change in quite a while. If so, can you please run '/usr/local/bin/gen_inline_reporting_data.plx --debug' and post the output here? This should give us precise information on where the breakage occurs.
Cheers,
 andreas

Ok, the timestamp for /var/log/reporting/inline is 25.02.2009 23:40:35 and the /usr/local/bin/gen_inline_reporting_data.plx --debug gives following error :

Timeframe is defaulting to 'today'

DBI connect('dbname=reporting','reporting',...) failed: FATAL:  could not open file "pg_tblspc/16519/16520/PG_VERSION": Permission denied

 at /PerlApp/Astaro/Reporting/ADBShelper.pm line 573

can't open database connection to 'reporting' (retry 1 of 3)

Error: FATAL:  could not open file "pg_tblspc/16519/16520/PG_VERSION": Permission denied



DBI connect('dbname=reporting','reporting',...) failed: FATAL:  could not open file "pg_tblspc/16519/16520/PG_VERSION": Permission denied

 at /PerlApp/Astaro/Reporting/ADBShelper.pm line 573

can't open database connection to 'reporting' (retry 2 of 3)

Error: FATAL:  could not open file "pg_tblspc/16519/16520/PG_VERSION": Permission denied



DBI connect('dbname=reporting','reporting',...) failed: FATAL:  could not open file "pg_tblspc/16519/16520/PG_VERSION": Permission denied

 at /PerlApp/Astaro/Reporting/ADBShelper.pm line 573

can't open database connection to 'reporting' (retry 3 of 3)

Error: FATAL:  could not open file "pg_tblspc/16519/16520/PG_VERSION": Permission denied