-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Something appears to be something odd going on with the git repos on
kernel.org, including both the git and linux trees. I believe that I've
tracked down the problem to differences that occur between the repos
located at the various IPs that kernel.org translates to (zeus-pub1:
204.152.191.5 and zeus-pub2: 204.152.191.37).
In this case, it appears that the repo located at zeus-pub1 has been
updated, but the changes haven't propagated over to zeus-pub2 yet. The
result is that one call fetches a list of objects, but the next call
goes to the other IP, and it can't find an object it needs, so it ends
up dying.
This is probably a temporary error that will periodically (and probably
very rarely) occur when pulling from a source with more than a single IP
and some lag before the mirror is updated.
Is this an issue that we need to watch for and program around (other
than forcing www.kernel.org's IP in /etc/hosts), or is it just one of
those things that should be such a rare occurrance that we shouldn't
have to worry about it?
Thanks,
Frank
- --
Frank Sorenson - KD7TZK
Systems Manager, Computer Science Department
Brigham Young University
frank@tuxrocks.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDI+PAaI0dwg4A47wRAgEhAKDPjvyHZwTSw/e+FwE5BXtpH2novACdGBaF
+R64XoAYx+WXGjbczO+ZQtY=
=vCRj
-----END PGP SIGNATURE-----
Frank Sorenson wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Something appears to be something odd going on with the git repos on
kernel.org, including both the git and linux trees. I believe that I've
tracked down the problem to differences that occur between the repos
located at the various IPs that kernel.org translates to (zeus-pub1:
204.152.191.5 and zeus-pub2: 204.152.191.37).
In this case, it appears that the repo located at zeus-pub1 has been
updated, but the changes haven't propagated over to zeus-pub2 yet. The
result is that one call fetches a list of objects, but the next call
goes to the other IP, and it can't find an object it needs, so it ends
up dying.
This is probably a temporary error that will periodically (and probably
very rarely) occur when pulling from a source with more than a single IP
and some lag before the mirror is updated.
Is this an issue that we need to watch for and program around (other
than forcing www.kernel.org's IP in /etc/hosts), or is it just one of
those things that should be such a rare occurrance that we shouldn't
have to worry about it?
From a gitweb perspective, one of the servers appears to be about 24
hours out of date as of Sun Sep 11 15:50:53 UTC 2005. Broken rsync process?
On Sun, Sep 11, 2005 at 11:54:03AM -0400, A Large Angry SCM wrote:
quoted
This is probably a temporary error that will periodically (and
probably very rarely) occur when pulling from a source with more
than a single IP and some lag before the mirror is updated.
Is this an issue that we need to watch for and program around (other
than forcing www.kernel.org's IP in /etc/hosts), or is it just one of
those things that should be such a rare occurrance that we shouldn't
have to worry about it?
From a gitweb perspective, one of the servers appears to be about 24
hours out of date as of Sun Sep 11 15:50:53 UTC 2005. Broken rsync process?
The filesystem on one of the machines got remounted read-only, so
nothing was being updated.
-- Nathan Laredo
laredo@kernel.org