savannah trailing sources?

savannah trailing sources?

[Aldy Hernandez]

[Ok, one more time with the right address.  Doh!]

Hi folks.

Is savannah supposed to trail sources on purpose?

Savannah:

   coqui:/tmp/x/gcc/gcc$ cvs status ChangeLog
   ===================================================================
   File: ChangeLog         Status: Up-to-date
    
      Working revision:    2.3607
      Repository revision: 2.3607  /cvsroot/gcc/gcc/gcc/ChangeLog,v

Sources:

   coqui:/source/uber/gcc$ cvs status ChangeLog
   ===================================================================
   File: ChangeLog         Status: Up-to-date
    
      Working revision:    2.3611
      Repository revision: 2.3611  /cvs/uberbaum/gcc/ChangeLog,v

Cheers.
Aldy

Re: savannah trailing sources?

[Aldy Hernandez]

> When system b mirrors system a by taking periodic snapshots it is pretty
> much a guarantee that system b will trail system a.

> 
> This really isn't an overseers issue.  We don't control Savannah.

I know.  I was just asking because savannah is the recommended way of
pulling anonymously (on the gcc web page).  And because it's trailing by
a few days, not just a few hours.

Thanks anyhow.

Aldy

Re: savannah trailing sources?

[Christopher Faylor]

On Sun, May 09, 2004 at 11:22:20AM -0400, Aldy Hernandez wrote:
>[Ok, one more time with the right address.  Doh!]
>
>Hi folks.
>
>Is savannah supposed to trail sources on purpose?
>
>Savannah:
>
>   coqui:/tmp/x/gcc/gcc$ cvs status ChangeLog
>   ===================================================================
>   File: ChangeLog         Status: Up-to-date
>    
>      Working revision:    2.3607
>      Repository revision: 2.3607  /cvsroot/gcc/gcc/gcc/ChangeLog,v
>
>Sources:
>
>   coqui:/source/uber/gcc$ cvs status ChangeLog
>   ===================================================================
>   File: ChangeLog         Status: Up-to-date
>    
>      Working revision:    2.3611
>      Repository revision: 2.3611  /cvs/uberbaum/gcc/ChangeLog,v
>
>Cheers.

When system b mirrors system a by taking periodic snapshots it is pretty
much a guarantee that system b will trail system a.

This really isn't an overseers issue.  We don't control Savannah.

cgf

Re: savannah trailing sources?

[Andreas Schwab]

Christopher Faylor <cgf@alum.bu.edu> writes:

> This really isn't an overseers issue.  We don't control Savannah.

But you control sourceware, and rsync access is broken since the move.
And ssh access is also broken.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: savannah trailing sources?

[Christopher Faylor]

On Sun, May 09, 2004 at 12:13:04PM -0400, Aldy Hernandez wrote:
>> When system b mirrors system a by taking periodic snapshots it is pretty
>> much a guarantee that system b will trail system a.
>
>>This really isn't an overseers issue.  We don't control Savannah.
>
>I know.  I was just asking because savannah is the recommended way of
>pulling anonymously (on the gcc web page).  And because it's trailing
>by a few days, not just a few hours.

That's probably because of the gcc.gnu.org IP address change.  Savannah
has also seemed to be having some rsync hanging problems lately.  There's
always three or four sitting around doing nothing at the end of the day.

cgf

Re: savannah trailing sources?

[Christopher Faylor]

On Sun, May 09, 2004 at 08:05:45PM +0200, Andreas Schwab wrote:
>Christopher Faylor <cgf@alum.bu.edu> writes:
>>This really isn't an overseers issue.  We don't control Savannah.
>
>But you control sourceware, and rsync access is broken since the move.

There have been plenty of accesses to rsync on the system since the
move.  In fact, I checked rsync when the system first came back up.

>And ssh access is also broken.

That's not broken either.  There have been plenty of ssh logins.  I logged
in shortly after the system came up.

There is a problem with slow propagation of the new IP address, of
course.  That's not a problem with specific services on the system,
though.

Also, the system itself has been inexplicably flaky since the move.
It's been going up and down.  The theory is that it's the aacraid driver
but why this is suddenly a problem after a system move hasn't been
explained.

cgf

Re: savannah trailing sources?

[Jeff Sturm]

On Sun, 9 May 2004, Christopher Faylor wrote:
> There is a problem with slow propagation of the new IP address, of
> course.  That's not a problem with specific services on the system,
> though.

Of course a long TTL exacerbates the problem.

;; ANSWER SECTION:
gcc.gnu.org.            86400   IN      A       12.107.209.250

But, I'm guessing this isn't under your control either.  The TTL of
sources.redhat.com is much more sane.

Jeff

Re: savannah trailing sources?

[Christopher Faylor]

On Sun, May 09, 2004 at 10:17:40PM -0400, Jeff Sturm wrote:
>On Sun, 9 May 2004, Christopher Faylor wrote:
>>There is a problem with slow propagation of the new IP address, of
>>course.  That's not a problem with specific services on the system,
>>though.
>
>Of course a long TTL exacerbates the problem.

Yes.  This is part of what I meant by slow propagation.

>;; ANSWER SECTION:
>gcc.gnu.org.            86400   IN      A       12.107.209.250
>
>But, I'm guessing this isn't under your control either.  The TTL of
>sources.redhat.com is much more sane.

I don't control the domain info for either, actually.  I do control
cygwin.com, FWIW.

I found out about the need to move the system shortly before Frank
Eigler sent out email to everyone.

The need to move quickly came about from an unfortunate set of
circumstances that no one was happy about.  I don't think we're likely
to ever have to do something like that again.

cgf

Re: savannah trailing sources?

[Matthew Galgoci]

On Sun, 9 May 2004, Christopher Faylor wrote:

> On Sun, May 09, 2004 at 10:17:40PM -0400, Jeff Sturm wrote:
> >On Sun, 9 May 2004, Christopher Faylor wrote:
> >>There is a problem with slow propagation of the new IP address, of
> >>course.  That's not a problem with specific services on the system,
> >>though.
> >
> >Of course a long TTL exacerbates the problem.
> 
> Yes.  This is part of what I meant by slow propagation.
> 
> >;; ANSWER SECTION:
> >gcc.gnu.org.            86400   IN      A       12.107.209.250
> >
> >But, I'm guessing this isn't under your control either.  The TTL of
> >sources.redhat.com is much more sane.
> 
> I don't control the domain info for either, actually.  I do control
> cygwin.com, FWIW.

If you want the ttl turned down for gcc.gnu.org I think I might be alble 
to arrange it.

3600 sounds about right. 

-- 
Matthew Galgoci
System Administrator and Sr. Manager of Ruminants
Red Hat, Inc
919.754.3700 x44155

Re: savannah trailing sources?

[Matthew Galgoci]

> > 3600 sounds about right. 
> 
> It's too late now.  That should have been done several days *before*
> the move to make the switch to the new IP address easier... 
> 
> Or are you planning another move?

I'm not planning another move. I was thinking as a matter of precaution, to
have the ttl set short. Red Hat purposefully has ttls set anywhere between
10 minutes and 1 hours, and this has proved beneficial.


-- 
Matthew Galgoci
System Administrator and Sr. Manager of Ruminants
Red Hat, Inc
919.754.3700 x44155

Re: savannah trailing sources?

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1317 bytes --]

Matthew Galgoci <mgalgoci@redhat.com> writes:

> On Sun, 9 May 2004, Christopher Faylor wrote:
>
>> On Sun, May 09, 2004 at 10:17:40PM -0400, Jeff Sturm wrote:
>> >On Sun, 9 May 2004, Christopher Faylor wrote:
>> >>There is a problem with slow propagation of the new IP address, of
>> >>course.  That's not a problem with specific services on the system,
>> >>though.
>> >
>> >Of course a long TTL exacerbates the problem.
>> 
>> Yes.  This is part of what I meant by slow propagation.
>> 
>> >;; ANSWER SECTION:
>> >gcc.gnu.org.            86400   IN      A       12.107.209.250
>> >
>> >But, I'm guessing this isn't under your control either.  The TTL of
>> >sources.redhat.com is much more sane.
>> 
>> I don't control the domain info for either, actually.  I do control
>> cygwin.com, FWIW.
>
> If you want the ttl turned down for gcc.gnu.org I think I might be alble 
> to arrange it.
>
> 3600 sounds about right. 

It's too late now.  That should have been done several days *before*
the move to make the switch to the new IP address easier... 

Or are you planning another move?

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: savannah trailing sources?

[Zack Weinberg]

Matthew Galgoci <mgalgoci@redhat.com> writes:

>> >;; ANSWER SECTION:
>> >gcc.gnu.org.            86400   IN      A       12.107.209.250
>> >
>> >But, I'm guessing this isn't under your control either.  The TTL of
>> >sources.redhat.com is much more sane.
>> 
>> I don't control the domain info for either, actually.  I do control
>> cygwin.com, FWIW.
>
> If you want the ttl turned down for gcc.gnu.org I think I might be alble 
> to arrange it.
>
> 3600 sounds about right. 

It hardly seems worthwhile _now_.  A day is a reasonable TTL when the
system isn't about to be moved IMHO - it should be dropped to an hour
or so, twenty-four hours _before_ the move, and then put back up
afterward.

Alternatively I think tinydns has a "this record will expire at
absolute time X, set TTLs accordingly" feature.

zw

Re: savannah trailing sources?

[Phil Edwards]

On Sun, May 09, 2004 at 10:55:19PM -0400, Matthew Galgoci wrote:
> > > 3600 sounds about right. 
> > 
> > It's too late now.  That should have been done several days *before*
> > the move to make the switch to the new IP address easier... 
> > 
> > Or are you planning another move?
> 
> I'm not planning another move. I was thinking as a matter of precaution, to
> have the ttl set short. Red Hat purposefully has ttls set anywhere between
> 10 minutes and 1 hours, and this has proved beneficial.

There's no point to wasting the bandwidth if another move is not planned.

-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

RE: savannah trailing sources?

[Dave Korn]

> -----Original Message-----
> From: gcc-owner On Behalf Of Jeff Sturm
> Sent: 10 May 2004 03:18
> To: Christopher Faylor
> Cc: overseers ; gcc 
> Subject: Re: savannah trailing sources?
> 
> On Sun, 9 May 2004, Christopher Faylor wrote:
> > There is a problem with slow propagation of the new IP address, of
> > course.  That's not a problem with specific services on the system,
> > though.
> 
> Of course a long TTL exacerbates the problem.
> 
> ;; ANSWER SECTION:
> gcc.gnu.org.            86400   IN      A       12.107.209.250
> 
> But, I'm guessing this isn't under your control either.  The TTL of
> sources.redhat.com is much more sane.
> 
> Jeff


  Erm, [it's slightly ambiguous from your post whether you're showing an old
stale record still in DNS somewhere or if you're only pointing at the length
of the TTL from the new record on the assumption it was the same in the old
record as it is now] but if that's the old IP address, then the problem is
not one of long TTL, but of the authoritative server not having been
updated, since that's what ns1.gnu.org is still reporting as the A record.

  And if that's the correct new IP address, then the problem isn't dns at
all, but that the machine is down, or there's some very bad routing info out
there, because traceroute to it dies for me at 12.119.93.62, which is
exactly where Kai Henningsen was reporting it to fail two days ago:

  8    26 ms    35 ms    29 ms  core2-pos15-1.ealing.ukcore.bt.net
[194.74.16.15
7]
  9    46 ms    29 ms    27 ms  transit1-pos4-0.ealing.ukcore.bt.net
[194.72.9.2
38]
 10    29 ms    29 ms    29 ms  t2c1-p1-0.uk-eal.eu.bt.net [166.49.168.13]
 11   104 ms   116 ms   104 ms  t2c1-p5-0.us-ash.eu.bt.net [166.49.164.74]
 12   121 ms   107 ms   107 ms  12.119.141.33
 13   108 ms   110 ms   113 ms  tbr2-p012901.wswdc.ip.att.net
[12.123.217.17]
 14   116 ms   113 ms   113 ms  gar1-p370.rlgnc.ip.att.net [12.122.3.61]
 15   115 ms   113 ms   113 ms  12.119.93.62
 16     *        *        *     Request timed out.
 17     *        *        *     Request timed out.
 18     *        *        *     Request timed out.

  So if anyone out there still is able to access gcc.gnu.org and isn't
having problems, their packets must be going by a different route to ours,
or there must be some selective filtering going on at that AT+T router.  It
would be great if someone who *can* access it would post a traceroute as
well.

  My betting is that there's some bogus routing info out there.  It's been
two days, and I queried the authoritative server.  It's not a DNS thing any
more.


    cheers, 
      DaveK
-- 
Can't think of a witty .sigline today....

Re: savannah trailing sources?

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

Christopher Faylor <cgf@alum.bu.edu> writes:

> On Sun, May 09, 2004 at 08:05:45PM +0200, Andreas Schwab wrote:
>>Christopher Faylor <cgf@alum.bu.edu> writes:
>>>This really isn't an overseers issue.  We don't control Savannah.
>>
>>But you control sourceware, and rsync access is broken since the move.
>
> There have been plenty of accesses to rsync on the system since the
> move.  In fact, I checked rsync when the system first came back up.
>
>>And ssh access is also broken.
>
> That's not broken either.  There have been plenty of ssh logins.  I logged
> in shortly after the system came up.
>
> There is a problem with slow propagation of the new IP address, of
> course.  That's not a problem with specific services on the system,
> though.
>
> Also, the system itself has been inexplicably flaky since the move.
> It's been going up and down.  The theory is that it's the aacraid driver
> but why this is suddenly a problem after a system move hasn't been
> explained.

The machine now has additional RAM.  This could be a bug with high
memory support, e.g. usage of wrong interfaces in the aacraid driver.
Or the new memory is broken.  I suggest to downgrade to 2GB and see
whether that helps,

Andreas
-- 
 Andreas Jaeger, aj@suse.de, http://www.suse.de/~aj
  SUSE Linux AG, Maxfeldstr. 5, 90409 Nürnberg, Germany
   GPG fingerprint = 93A3 365E CE47 B889 DF7F  FED1 389A 563C C272 A126

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: savannah trailing sources?

[Andreas Schwab]

Christopher Faylor <cgf@alum.bu.edu> writes:

> On Sun, May 09, 2004 at 08:05:45PM +0200, Andreas Schwab wrote:
>>Christopher Faylor <cgf@alum.bu.edu> writes:
>>>This really isn't an overseers issue.  We don't control Savannah.
>>
>>But you control sourceware, and rsync access is broken since the move.
>
> There have been plenty of accesses to rsync on the system since the
> move.  In fact, I checked rsync when the system first came back up.
>
>>And ssh access is also broken.
>
> That's not broken either.  There have been plenty of ssh logins.  I logged
> in shortly after the system came up.

Just trying at this very moment, it is *still* broken, both rsync and ssh.

> There is a problem with slow propagation of the new IP address

Surely not, since I can connect to sourceware, but the connection just
times out.

$ ssh -v gcc.gnu.org
OpenSSH_3.8p1, SSH protocols 1.5/2.0, OpenSSL 0.9.7d 17 Mar 2004
debug1: Reading configuration data /suse/schwab/.ssh/config
debug1: Applying options for gcc.gnu.org
debug1: Applying options for *.org
debug1: Applying options for *
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to gcc.gnu.org [12.107.209.250] port 22.
[timout]

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."