Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 2 subscribers
  • Views 13686 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

After update to 7.3 not getting daily executive report

AndreyS
/usr/local/bin # report_render.plx --type daily --sendmail
------
product: ASG | Astaro Security Gateway Software
running get_summary
DBD:[[:P]]g::st execute failed: ERROR: invalid page header in block 4356 of relation "accounting"
DBD:[[:P]]g::st execute failed: ERROR: invalid page header in block 4356 of relation "accounting"

/var/log/system.log
 
2008:09:04-09:40:20 (none) postgres[13697]: [3-1] LOG:  unexpected EOF on client connection
2008:09:04-09:40:21 (none) ulogd[2983]: input key `flow.start.sec' already has source
2008:09:04-09:40:21 (none) ulogd[2983]: stack_fsm_timer_cb: error
2008:09:04-09:40:27 (none) postgres[13737]: [3-1] ERROR:  invalid page header in block 4358 of relation "accounting"
2008:09:04-09:40:27 (none) postgres[13737]: [3-2] STATEMENT:  INSERT INTO public.accounting
2008:09:04-09:40:27 (none) postgres[13737]: [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
2008:09:04-09:40:27 (none) postgres[13737]: [3-4] _sec,flow_duration) VALUES ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11);
2008:09:04-09:40:27 (none) ulogd[2983]: pg1: ERROR:  invalid page header in block 4358 of relation "accounting"
2008:09:04-09:40:27 (none) ulogd[2983]: pg1: commit failed
2008:09:04-09:40:32 (none) ulogd[2983]: input key `flow.start.sec' already has source
2008:09:04-09:40:32 (none) ulogd[2983]: stack_fsm_timer_cb: error


This thread was automatically locked due to age.
Parents
  • 0
    Iive had this problem too.  I've updated to v7.301 and still have the problem. 

    I droped the table and recreated it via the above instructions, and it seems good now. 

    Specifically the instructions are:
    1.)  /etc/init.d/ulog stop
    2.)  /etc/init.d/syslogng stop
    3.)  /var/storage/pgsql/init/reporting_db_init.sh
    4.)  /etc/init.d/syslogng start
    5.)  /etc/init.d/ulog start

    Function complete.
  • 0 in reply to ewilson@ebiz.cx
    Iive had this problem too.  I've updated to v7.301 and still have the problem. 

    I droped the table and recreated it via the above instructions, and it seems good now. 

    Specifically the instructions are:
    1.)  /etc/init.d/ulog stop
    2.)  /etc/init.d/syslogng stop
    3.)  /var/storage/pgsql/init/reporting_db_init.sh
    4.)  /etc/init.d/syslogng start
    5.)  /etc/init.d/ulog start

    Function complete.


    I dont know mutch about Databases.
    How can I drope teh tables??
    I have the same problem and I dont get any executive report
  • 0 in reply to zbrv-1
    I dont know mutch about Databases.
    How can I drope teh tables??
    I have the same problem and I dont get any executive report


    The 3rd step above will drop and re-initialize the tables automatically. Just execute the above list in the order given.

    Cheers,
     andreas
Reply
  • 0 in reply to zbrv-1
    I dont know mutch about Databases.
    How can I drope teh tables??
    I have the same problem and I dont get any executive report


    The 3rd step above will drop and re-initialize the tables automatically. Just execute the above list in the order given.

    Cheers,
     andreas
Children
  • 0 in reply to andreas
    hi all,

    is there a way, to re-import the moved reporting files?

    Cause losing the reporting info, i can´t make statements about load, web-traffic and so on over the last year.

    i´ve a similar problem in the logs (not impacting the report files yet, but who knows), since updating up to 304; so i would do the re-initialisation, but don´t wanna lose my possiblities to reflect the last months load.

    CU
    Thomas
  • 0 in reply to tkaufi
    What you moved away were the broken database backend files. If they could be read or repaired, we'd do so instead of re-initializing the database tables. Depending on which tables are broken, it might not be necessary to wipe them all, but a lot of manual work is involved in doing this selectively, and this is not something we encourage our clients to do so. The data in these databases is not kept for a year (maximum 6 months, depending on your configuration in Reporting::Settings), so I assume you do refer to the graphs? If yes, don't worry, the graphs are not affected by this at all.
    Regarding the similar problem with the logfiles - I am not sure what you could mean with this, I am not aware about any bugs regarding loss/corruption of logfiles. Could you please add some detailed information about this?

    Cheers,
     andreas
  • 0 in reply to andreas
    Hi 
    I was reading thid tread & I think I am in a similar situation. My partition /var/storage is full & the folder pgsql in taking all the space. I think this procedure will solve my problem but, do we really need to reboot?

    Thanks
  • 0 in reply to inle
    hi

    @andreas: the "problem with the logfiles" is quite mistakable, we have similar psql error messages in the logs, i.e. system log:
    postgres[25467]: [3-1] LOG: unexpected EOF on client connection 
    which showing up every 5 min

    And
     ERROR:  duplicate key value violates unique constraint "primary_l"
    2008:11:04-11:02:30 (none) postgres[5583]: [3-2] STATEMENT:  INSERT INTO l ( cluster_id, message_id, recipient, sender, result, result_time, reason, reason_extra, msglog,
    2008:11:04-11:02:30 (none) postgres[5583]: [3-3]  received, subject, size, src, attachment ) VA.....
    which shows up frequently


    Ok, if the graphical bars are untouched, i can live with dropping all the reporting tables like described before

    Thomas

    Cu
    Thomas
  • 0 in reply to tkaufi

    postgres[25467]: [3-1] LOG: unexpected EOF on client connection 

    And
     ERROR:  duplicate key value violates unique constraint "primary_l"


    You can safely disregard this, it is just clutter which has not yet been stripped out. 
    Cheers,
     andreas
Unfiltered HTML