Opened 12 years ago
Closed 11 years ago
#7 closed (fixed)
debug intermittent 500 errors in report_data_to_gmoc
Reported by: | chaos@bbn.com | Owned by: | somebody |
---|---|---|---|
Priority: | major | Milestone: | |
Component: | Infrastructure | Version: | |
Keywords: | Cc: | ||
Dependencies: |
Description
At GPO, we receive approximately half a dozen reporting errors per day of the form:
From: root@gpolab.bbn.com (Cron Daemon) Date: Sat, 21 Jul 2012 14:01:18 -0400 (EDT) To: ganglia@gpolab.bbn.com Subject: [gpo-ops] Cron <ganglia@chasel> /usr/bin/report_data_to_gmoc 500 Internal Server Error: <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>500 Internal Server Error</title> </head><body> <h1>Internal Server Error</h1> <p>The server encountered an internal error or misconfiguration and was unable to complete your request.</p> <p>Please contact the server administrator, root@localhost and inform them of the time the error occurred, and anything you might have done that may have caused the error.</p> <p>More information about this error may be available in the server error log.</p> <hr> <address>Apache/2.2.3 (Red Hat) Server at <a href="mailto:root@localhost">gmoc-db.grnoc.iu.edu</a> Port 443</address> </body></html> at /usr/bin/report_relations line 34 main::__ANON__('500 Internal Server Error: <!DOCTYPE HTML PUBLIC "-//IETF//DT...') called at /usr/bin/report_relations line 316 Execution of /usr/bin/report_relations failed!
These errors always seem to be received during the reporting run which is on the hour (i.e. the datestamp on the error is always NN:01:MM
for some hour NN and second MM values). Diagnose and fix these intermittent failures.
Change History (2)
comment:1 Changed 12 years ago by
comment:2 Changed 11 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
Closing this, because i believe we addressed this particular error. There are some intermittent issues with submission and retrieval, but we should create new tickets for these.
Note: See
TracTickets for help on using
tickets.
This is not a time-critical problem, and no one should worry about debugging it until August. I'm just making a ticket so we have one on file.