Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 26 replies
  • Subscribers 2 subscribers
  • Views 13669 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.
  • 0 in reply to jabuin
    Almost forgot to say.. This is just a workaround, use the code at uor risk and remember to save uor backups and config file.
    By the way here one missing parts. Should be ok to run after the maintenace by superuser (root). 


    # killall ctasd


    Best Regards
  • 0 in reply to jabuin
    Almost forgot to say.. This is just a workaround, use the code at uor risk and remember to save uor backups and config file.
    By the way here one missing parts. Should be ok to run after the maintenace by superuser (root). 


    # killall ctasd


    Best Regards
  • 0 in reply to xXlAinXx
    Why kill these?

    By "after the maintenance by the superuser (root)", do you mean after the reboot?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Uor thought is high, it's for forcing syncronyze some patterns after the reboot and deal with the
    CFCTcpServer Thread Exception on Create/listen socket: Error (98) related issue, wich probably the machine could be affected to.
  • 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
  • 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
Unfiltered HTML