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

Bug#587493: choose-mirror: Strange wget error message in the installation log

On Tuesday 29 June 2010, Petter Reinholdtsen wrote:
> [Frans Pop]
> > So, one wget results in a 404. As choose-mirror tries various
> > possible suites and codenames and wgets are used for other purposes
> > as well, a 404 is always a possibility.
> Sure, but all the URLs listed in the log are working, so it seem
> strange that one of them give 404.

So either it's due to a temporary mirror issue (which you'd want to know 
about), or it's from an unlogged wget. Or it's from a wget from a 
subprogram called by choose-mirror, in which case you patch won't even 

> > It's not bogus. It's a useful message for troubleshooting and
> > debugging.  The only thing that is a pity is that logging of the
> > error messages to stderr gets delayed until the component completes.
> It is bogus, as all the URLs in the log are working when I test them
> manually, and it is close to impossible to figure out what URL was
> failing.

No, it's not bogus. There *is* a wget that's failing. Whether it affects 
the end result of the install or not is another matter.

wgets in choose-mirror can fail for various valid reasons. Most of them you 
want to know about for troubleshooting purposes.
Examples are: (temporarily) broken mirrors, incomplete mirrors, broken 
proxies. I've seen 403s and 404s that have helped a lot tracing the cause 
of failed installs.

Removing valid information from logs for cosmetic reasons is wrong.

> > > The URLs in the log seem to work, so I do not understand why wget is
> > > complaining.  Is there some other wget calls that are not reported
> > > to the log?
> >
> > Did you check the code?
> Yes.  Only found the two mentioned in the patch, and neither seem to
> use a non-existing URL. :/

So, you'll need to look a bit deeper. Usually we fix the *cause* of errors. 
We don't suppress errors for cosmetic reasons.

> >> The only wget calls I find in choose-mirror do not throw away error
> >> messages.  Perhaps they should?  If so, this untested patch should
> >> implement it:
> >
> > NACK. The errors are too useful to suppress.
> I disagree.  The error in question is almost useless.  There is no way
> to see which URL was missing, and the message show up in the wrong
> location in the log.  A useful error message would make it possible to
> figure out what is wrong.  This one do not. :(

But it's currently all we have! And, as mentioned before, it *has* helped 
me a number of times in the past, both while tracing issues from 
installation reports and while debugging.

Improving the error handling is valid. Simply removing the messages without 
replacing them with something else (better) is plain wrong.

> If the error message continue to come from d-i, we need to filter it
> out in debian-edu, but I thought it best to try to get rid of it
> first.

If you can't come up with a proper solution for choose-mirror then that is 
the correct way to go. The primary purpose of the syslog is to help users 
and developers to find the cause of issues. Removing real error messages 
for cosmetic reasons does not improve the installer.

Reply to: