public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nathan Laredo <laredo@hera.kernel.org>
To: Michael Krufky <mkrufky@m1k.net>
Cc: Alistair John Strachan <s0348365@sms.ed.ac.uk>,
	webmaster@kernel.org, lkml <linux-kernel@vger.kernel.org>,
	Michael Krufky <mkrufky@gmail.com>
Subject: Re: [KORG] GITWEB doesn't show any DIFF's
Date: Tue, 17 Jan 2006 10:53:53 -0800	[thread overview]
Message-ID: <20060117185353.GA28302@hera.kernel.org> (raw)
In-Reply-To: <43CD36FC.4020801@m1k.net>

On Tue, Jan 17, 2006 at 01:27:08PM -0500, Michael Krufky wrote:
> >Also, try s/www/zeus2/ in the URL to see if it's a problem 
> >specific to one server (I wonder if the reason some of us have 
> >problems and others don't is that we are being http load 
> >balanced).
> >
> Well, when I used zeus2 directly, I can see the diff...... I tried doing 
> the same with  zeus1, and in fact, the diff does not show.
> 
> That solves it!
> 
> Zeus2 is working correctly, Zeus1 isnt showing us any diff's ......
> 
> Thanks for the help, now, can this be fixed?

A couple things were happening here...

zeus1 suffered a cpu fan failure and was shutdown by external 
hardware that rebooted it into a different kernel (which ended
up resolving the 64-bit sendfile issue (older kernel)

load average on zeus1 was well over 150 with the older kernel--
and a bit of investigation went into whether or not the kernel
was the cause, but in the process of investigation, a third problem 
was discovered...

Logwatch left 39GB of turds in /tmp filling up the entire root
filesystem causing gitweb to fail because it had nowhere to
write temp files (also why the bandwidth graph wasn't showing
up as well for zeus1).

The root filesystem is only 50GB on that machine while /var/log
is hundreds of gigabytes...

/tmp was cleared out, the system is now on a more stable kernel
that should resolve the 64-bit sendfile issues, and the system
load appears to now be at a reasonable level...

We will be updating the kernel on the other machine after the
current one proves stable with 64-bit sendfile support.

That should fix the problem with apache not being able to
serve DVD images...

-- Nathan Laredo
laredo@kernel.org

      reply	other threads:[~2006-01-17 18:55 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-01-17 14:01 [KORG] GITWEB doesn't show any DIFF's Michael Krufky
2006-01-17 17:39 ` Alistair John Strachan
2006-01-17 17:52   ` Diego Calleja
2006-01-17 18:07     ` Jesper Juhl
2006-01-17 18:15       ` Michael Krufky
2006-01-17 17:59   ` Michael Krufky
2006-01-17 18:17     ` Alistair John Strachan
2006-01-17 18:27       ` Michael Krufky
2006-01-17 18:53         ` Nathan Laredo [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060117185353.GA28302@hera.kernel.org \
    --to=laredo@hera.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mkrufky@gmail.com \
    --cc=mkrufky@m1k.net \
    --cc=s0348365@sms.ed.ac.uk \
    --cc=webmaster@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox