Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 9 replies
  • Subscribers 3 subscribers
  • Views 2525 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

ASG 8.301 Hung up

JimmyM
I didn't get my daily report this morning so when I went to log in to see if anything was amiss, I could not connect via browser I would get a 500 error.
Without a screen or keyboard on my ASG box, I shut it down and restarted it via the power button.

My logs from yesterday morning show the below entries in the system log.
2012:04:12-01:50:15 firewall1 postgres[26487]: [2-1] WARNING:  pgstat wait timeout
2012:04:12-01:50:25 firewall1 postgres[8162]: [6-1] WARNING:  pgstat wait timeout
2012:04:12-01:50:35 firewall1 postgres[8162]: [7-1] WARNING:  pgstat wait timeout
2012:04:12-01:50:45 firewall1 postgres[8162]: [8-1] WARNING:  pgstat wait timeout
2012:04:12-01:50:55 firewall1 postgres[8162]: [9-1] WARNING:  pgstat wait timeout
2012:04:12-01:51:05 firewall1 postgres[8162]: [10-1] WARNING:  pgstat wait timeout
2012:04:12-01:50:30 firewall1 postgres[26499]: [2-1] WARNING:  pgstat wait timeout

It would still pass traffic but I checked several logs and today's logs have entries from yesterday, but they all seem to stop at around 1:48AM on Apr 12.


This thread was automatically locked due to age.
  • 0
    Have you tried reinitializing the Reporting databases?  Just be aware that this deletes all history in Reporting.

    Cheers - Bob
  • 0 in reply to BAlfson
    Have you tried reinitializing the Reporting databases?  Just be aware that this deletes all history in Reporting.

    Cheers - Bob


    Haven't tried that. But can't hurt. I don't have a lot of history in there that I really need.
  • 0 in reply to JimmyM
    Well, it did it again.

     postgres[20744]: [2-1] WARNING:  pgstat wait timeout

    I did the report database re-initialization last week as suggested, but it apparently didn't change anything. I was running one of the lower versions of v8 previously for months with no problems. What has changed in the postgresql db since then?
  • 0 in reply to JimmyM
    And again just the other day.
    I've run ASG for months on end with no issues in the past. However, this is the first time I've ever used the remote log file archive via FTP before. Could gathering the log file data cause this sort of issue? Is the logged data even stored in the DB inside ASG?
  • 0
    Jimmy, I think the info goes into Reporting as it's recorded in the log files, so that souldn't be related.  If this is a unit with paid support, I bet Astaro would like to have a look at it.  If not, you might consider participating in the V9 beta going on right now.  Your issues might get some developer attention if they're reproducible in the beta.

    Cheers - Bob
  • 0 in reply to BAlfson
    Jimmy, I think the info goes into Reporting as it's recorded in the log files, so that souldn't be related.  If this is a unit with paid support, I bet Astaro would like to have a look at it.  If not, you might consider participating in the V9 beta going on right now.  Your issues might get some developer attention if they're reproducible in the beta.

    Cheers - Bob

    Nah, Bob. This is just a home user licensed machine. I'm exporting the logs to a local FTP server to be read into a MySQL DB (on FTP server) by a Java process I wrote to run a few reports on. My kids need more and more access to the internet for school as well as having WiFi access to the internet via smartphones, tablets, etc. I just want to be able to do a little eavesdropping.
    Although I have installed v9beta on a VM to have a look around I was hoping to have a more stable solution. The wife hates it when things just stop working. When the postgres process coughs, the ASG box stops handing out DHCP addresses.
    Although v9 is awfully pretty.
  • 0 in reply to JimmyM
    OK. It's hung up (same problem) twice on 8.302 and again after upgrading to 8.303.
    Getting a little frustrated here.
  • 0 in reply to BAlfson
    Have you tried reinitializing the Reporting databases?  Just be aware that this deletes all history in Reporting.

    Cheers - Bob


    Having these same issues... the link to Reinitializing the Reporting databases appears to go nowhere... any chance to get this info once again?

    I'm experiencing this presently:
    2013:10:28-15:00:36 astaro ulogd[6303]: pg1: connect: FATAL:  "pg_tblspc/16546/16547" is not a valid data directory
    2013:10:28-15:00:21 astaro postgres[13715]: [2-2] DETAIL:  File "pg_tblspc/16546/16547/PG_VERSION" is missing.
    2013:10:28-15:00:26 astaro postgres[13716]: [2-1] FATAL:  "pg_tblspc/16546/16547" is not a valid data directory