[7.390] Bug: Executive Report Manual Generation

Hi,
does the generation work for the nightly executive reports? Can you please check in /opt/tmpfs when the last executive report was generated (date&time)? Can you then try to create a report manually again and watch this directory for a couple of minutes if the executive report in there is replaced?

Thank you,
 andreas

Hi,
does the generation work for the nightly executive reports? Can you please check in /opt/tmpfs when the last executive report was generated (date&time)? Can you then try to create a report manually again and watch this directory for a couple of minutes if the executive report in there is replaced?

I have daily/weekly reports turned off.  However, I have monthly reports turned on, with PDF options on.

I show no archived reports at all, and /opt/tmpfs only has btime, hwinfo, run, and ufostatus right now.

While watching /opt/tmpfs during a manual report generation, I see no new files there.  Here's the date and time stamps for that folder's files.

loginuser@router:/opt/tmpfs > ls -laF *
-rw-r--r-- 1 root root      4 Feb  6 11:19 btime
-rw-r--r-- 1 root root 193723 Feb  6 11:20 hwinfo
-rw-r--r-- 1 root root     21 Feb  6 11:18 ufostatus

run:
total 24
drwxr-xr-x 3 root root  4096 Feb 11 18:14 ./
drwxrwxrwt 3 root root  4096 Feb 13 09:41 ../
-rw------- 1 root root 12288 Feb 13 09:45 repdispatcher.db
-rw-r--r-- 1 root root     0 Feb 13 09:46 repdispatcher.db.lock
drwxr-xr-x 2 root root  4096 Feb  6 11:17 sudo/


I clicked the manual generation button at 9:45, so it's locking/writing to that DB, I suppose.

-rw------- 1 root root 12288 Feb 13 09:45 repdispatcher.db
-rw-r--r-- 1 root root     0 Feb 13 09:46 repdispatcher.db.lock
drwxr-xr-x 2 root root  4096 Feb  6 11:17 sudo/


I clicked the manual generation button at 9:45, so it's locking/writing to that DB, I suppose.

I should add that the file size doesn't change and the time stamp on the db doesn't change after the initial click either.  The only time stamp that changes during the "generation" is the lock file....

run:
total 24
drwxr-xr-x 3 root root  4096 Feb 11 18:14 ./
drwxrwxrwt 3 root root  4096 Feb 13 09:48 ../
-rw------- 1 root root 12288 Feb 13 09:45 repdispatcher.db
-rw-r--r-- 1 root root     0 Feb 13 09:52 repdispatcher.db.lock
drwxr-xr-x 2 root root  4096 Feb  6 11:17 sudo/

-rw------- 1 root root 12288 Feb 13 09:45 repdispatcher.db
-rw-r--r-- 1 root root     0 Feb 13 09:46 repdispatcher.db.lock
drwxr-xr-x 2 root root  4096 Feb  6 11:17 sudo/


I clicked the manual generation button at 9:45, so it's locking/writing to that DB, I suppose.

I should add that the file size doesn't change and the time stamp on the db doesn't change after the initial click either.  The only time stamp that changes during the "generation" is the lock file....

run:
total 24
drwxr-xr-x 3 root root  4096 Feb 11 18:14 ./
drwxrwxrwt 3 root root  4096 Feb 13 09:48 ../
-rw------- 1 root root 12288 Feb 13 09:45 repdispatcher.db
-rw-r--r-- 1 root root     0 Feb 13 09:52 repdispatcher.db.lock
drwxr-xr-x 2 root root  4096 Feb  6 11:17 sudo/

I'm not sure if it's related, but here are some entries in the system messages log ... this appears to repeat over and over...

2009:02:13-09:45:02 router /usr/sbin/cron[4224]: (root) CMD (/sbin/auisys.plx --nosys)

2009:02:13-09:45:02 router /usr/sbin/cron[4223]: (root) CMD (   /usr/local/bin/reportcontrol.sh)

2009:02:13-09:45:02 router /usr/sbin/cron[4225]: (root) CMD (nice -n19 /usr/local/bin/create_rrd_graphs.plx)

2009:02:13-09:45:03 router postgres[4207]: [3-1] ERROR:  invalid page header in block 734 of relation "accounting"

2009:02:13-09:45:03 router postgres[4207]: [3-2] STATEMENT:  INSERT INTO public.accounting

2009:02:13-09:45:03 router postgres[4207]: [3-3]  (ip_saddr,ip_daddr,ip_protocol,l4_dport,raw_in_pktlen,raw_in_pktcount,raw_out_pktlen,raw_out_pktcount,flow_start_day,flow_start

2009:02:13-09:45:03 router postgres[4207]: [3-4] _sec,flow_duration) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11);

2009:02:13-09:45:03 router ulogd[3201]: pg1: ERROR:  invalid page header in block 734 of relation "accounting" 

2009:02:13-09:45:11 router ulogd[3201]: input key `flow.start.sec' already has source

2009:02:13-09:45:12 router postgres[4254]: [3-1] ERROR:  invalid page header in block 734 of relation "accounting"

2009:02:13-09:45:12 router postgres[4254]: [3-2] STATEMENT:  INSERT INTO public.accounting

2009:02:13-09:45:12 router postgres[4254]: [3-3]  (ip_saddr,ip_daddr,ip_protocol,l4_dport,raw_in_pktlen,raw_in_pktcount,raw_out_pktlen,raw_out_pktcount,flow_start_day,flow_start

2009:02:13-09:45:12 router postgres[4254]: [3-4] _sec,flow_duration) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11);

2009:02:13-09:45:12 router ulogd[3201]: pg1: ERROR:  invalid page header in block 734 of relation "accounting" 

2009:02:13-09:45:13 router postgres[4249]: [3-1] ERROR:  invalid page header in block 734 of relation "accounting"

2009:02:13-09:45:13 router postgres[4249]: [3-2] STATEMENT:  SELECT transform_SI(CAST(sum(raw_in_pktlen + raw_out_pktlen) AS BIGINT),1) as bandwidth, transform_common(count(*))

2009:02:13-09:45:13 router postgres[4249]: [3-3]  as connections FROM accounting

2009:02:13-09:45:15 router postgres[4260]: [3-1] ERROR:  invalid page header in block 734 of relation "accounting"

2009:02:13-09:45:15 router postgres[4260]: [3-2] CONTEXT:  automatic vacuum of table "reporting.public.accounting"

2009:02:13-09:45:17 router ulogd[3201]: input key `flow.start.sec' already has source

I'm not sure if it's related, but here are some entries in the system messages log ... this appears to repeat over and over...

2009:02:13-09:45:03 router postgres[4207]: [3-1] ERROR:  invalid page header in block 734 of relation "accounting"

2009:02:13-09:45:03 router ulogd[3201]: pg1: ERROR:  invalid page header in block 734 of relation "accounting" 

Sorry to say so, but this looks like the accounting database is hosed :/
First thing you need to do is find out which databases are affected. Log in to the machine using SSH, then run "psql -U reporting reporting" to enter the postgres shell. Now type \dt to see a list of tables:

reporting=> \dt

                List of relations

 Schema |        Name        | Type  |   Owner                

--------+--------------------+-------+-----------

 public | accounting         | table | reporting

 public | accounting_archive | table | reporting

 public | auth               | table | reporting

Then run vacuum on every table in turn:

 reporting=> vacuum accounting;

 VACUUM

If the database responds with "VACUUM", the table is fine, an "ERROR" message usually points to a broken table. Please not that VACUUM can take some time on large tables and slow machines. 

Now that you identified the broken tables (at least accounting is broken, in your case), 
you can use psql to drop all objects depending on that table and that table itself. For most reporting tables there is an associated view named _data (for example, "accounting" -> "accounting_data"), then copy&paste the statements for creating the table, the indices (listed directly after the table definition) and the views you just dropped above from /usr/share/postgresql/contrib/astaro_reporting_tables.sql:

reporting=> drop view accounting_data;

DROP VIEW

reporting=> drop table accounting;

DROP TABLE

reporting=> create table accounting (

reporting(>         ip_saddr                        bigint,



(shortened for brevity)



reporting(> );

NOTICE:  CREATE TABLE will create implicit sequence "accounting__rowno_seq" for serial column "accounting._rowno"

NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "accounting_pkey" for table "accounting"

CREATE TABLE

create index accounting_dayidx on accounting (flow_start_day);

CREATE INDEX

reporting=> create view accounting_data as



(...)



reporting->                 ip_saddr, ip_daddr, ip_protocol, l4_dport, dayabs;

CREATE VIEW

The exact data to create the tables varies, you need to look at the file mentioned above for the exact create statements.

Unfortunately, there's no easier way of doing this. If you have support, feel free to contact Astaro Support, mention that you have a broken accounting database, and they'll help you through.

Regards,
 andreas

It was the accounting table that was corrupt.  Your instructions worked perfectly, so I'm happy to say executive reporting is up and running fine.

Thanks!