savannah-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [savannah-help-public] Web interface doesn't work at 4am


From: Bob Proulx
Subject: Re: [savannah-help-public] Web interface doesn't work at 4am
Date: Tue, 14 May 2013 15:35:37 -0600
User-agent: Mutt/1.5.20 (2009-06-14)

Richard Stallman wrote:
> The housekeeping needs to be done, and 4am is a fine time to do it.

Sorry.  I was mistaken.  The servers run natively in the UTC timezone.
4am Boston time would be 8am UTC.  The daily cron task is set to start
at 6:25am UTC daily.  That is 2:25am US/Eastern time.  They should be
well done and gone by 4am Boston time.

I have added additional monitoring.  So far I have not had a timeout
from the web interface in the last 24 hours.  I am polling it every
five minutes looking for delays and other problems.  I am looking from
off the local network so that the routers between are also being
end-to-end tested.  The load average on both systems look reasonable.
The process status looks okay.  I don't see any related errors in the
logs.  I was hoping I would be able to experience the problem myself
during that time period and then would be able to debug it.

> Maybe there is a way to turn off the time-out.
> If they did not time out, they would work, just slowly.

There isn't really a timeout on the Savannah side.  Your web browser
is likely timing out and causing the timeout you are seeing but that
is a timeout on your client and not on the Savannah server.

For a little description of the Savannah web interface the Apache2 web
server runs on frontend.savannah.gnu.org running an Apache PHP module
directly in Apache.  Savannah's PHP code accesses the MySQL database
on internal.savannah.gnu.org over tcp.  If the MySQL connection fails
or times out then an error display reporting the database connection
failure will be displayed.  If Savannah's Apache web server fails or
times out then your web browser will display a generic timeout
message.  Both machines are virtual systems and if the underlying host
is too busy then either of those systems may be reporting idle but
still acting slow.

The next time you see this problem can you note the exact time and
error that occurred?  Also please report any additional information
that you think might help identify this problem such as ability or not
to be able to ping it.  Perhaps it is a network connectivity issue?

I will continue to increase the monitoring capability so that we can
track this better.  I have just today added additional monitoring and
tracking and will need to look to tomorrow to see if anything in the
new history looks suspect.

Bob



reply via email to

[Prev in Thread] Current Thread [Next in Thread]