I don't think we want to die during the 'for /next mirror()' loop.
An interesting point but perhaps still add a debug statement for
information?
if a mirror is busy (503), or is missing a tarball (404), we don't
want it to die, we want it to try next mirror.
does it follow the referrer for the 3xx error? should it? its gpg
signed, so, what is worse that could happen? mirror admin wants to
redirect tmp?
How would a 3xx error be generated to begin with? I would not want
mirror admins doing any modification of the rsync data.
actually, it all looks like it's in ram till it writes to tmpdir/fsy
at. 681..
so, a full tmpdir will still pull from the first mirror, but with my
patches to Util.pm, it won't even try if tmpdir is missing or read only.
Util.pm MIGHT need to check for minimum free space, but I think that
is not necessary at this time.
which already looks like it has this:
open(TMP, ">$content_file") || die "fatal: can't write to content
temp file $content_file: $!\n";
binmode TMP;
print TMP $content;
close(TMP);
I suggest this:
open(TMP, ">$content_file") || die "fatal: can't open content temp
file $content_file: $!\n";
binmode TMP;
print TMP $content || die "fatal: can't write to content temp file
$content_file: $!\n";
close(TMP);
The check that the print worked and the tmp dir is moving in the write
direction.
which bring up another point if http_get() runs out of RAM, there
isn't anything to catch that.
The error trapping is pretty minimal.
so, I am going to add the above patch to my bug after I try it out.
if this works, I will try to have out third shift guys contact admins
at the 'buggy' sa installs and see if we can't get them to test these
patches.
Can you add the current patch to the bugzilla note for Util.pm and
sa-update.raw? I'll test em and make sure they compile/work for me.
Otherwise, sounds like a plan. I'm all for contacting them ahead of
time and seeing what is causing their real-world issue as well.
Regards,
KAM
