[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[leafnode-list] Re: 423 Bad article number, ?was Re: leafnode-2.0.0.alpha20061010a snapshot available
On Sun, Dec 03, 2006 at 03:25:23PM +0100, clemens fischer wrote:
> On Fri, 1 Dec 2006 23:45:45 +0100 Martin wrote:
> > On Fri, Dec 01, 2006 at 09:16:19PM +0100, clemens fischer wrote:
> >> 2006-12-01_16:35:32.98216 GROUP gmane.comp.sysutils.supervision.general
> >> 2006-12-01_16:35:33.02053 211 1304 46 1349 gmane.comp.sysutils.supervision.general
> >> 2006-12-01_16:35:33.02871 XOVER 1349-1349
> > Only one article to fetch.
> since i cannot check the article in question, i cannot offer but a
> theory: many ezmlm-handled mailinglists are beeing spammed lately. this
> article might be spam. gmane keeps its overview data, but refuses to
> send it because it has been marked as spam.
I guess so, too. Nonetheless: fetchnews does not work as expected. It
does not matter, why this article disappeared. It is not there any more,
and that's what fetchnews has to handle.
> i just tried to use the gmane web interface to get at that article, but
> only get "connection refused".
Web interfaces are generally ... erm ... not my favourites. And since
fetchnews uses NNTP, my favourite way to check things out is using NNTP.
I want to avoid timeouts. Therefore I write some short files, e.g.
| authinfo user itsme@myhost
| authinfo pass naturallysecret
| group gmane.comp.sysutils.supervision.general
| article 1349
Then I use netcat to connect and send to the server. As I read somewhere
on the net, bash 3.0 should be able to connect to other hosts using TCP,
but netcat worked and still works.
| $ netcat news.gmane.org nntp < orderfile
Now you can read the outputs of news.gmane.org. Most likely they will be
the same as your cited logfile.
(In case you forget the "quit" on the last line or mistyped it: wait for
the timeout or kill netcat.)
> >> > +if (artno_server == 0) artno_server = -1;
> >> > return artno_server;
> >> > }
> > This is a quick && dirty hackaround. Since then I had no other side
> > effects, everything seems to work well. Be aware: There is the
> > possibility of being "-1 articles fetched" or other strange occurences.
> so the real fix would be to check if articles have been received from
> this particular server at all and rather try to get articles from the
> next group on it than switching to the next server, correct? maybe fail
> the server only after a (configurable) minimal number of errors or if
> the current group is the only or last one on it.
The "real" fix would be to do some better error-handling in
getarticles() and in the calling place. Maybe negative numbers could be
reserved for errors, and a total of zero fetched articles could be given
back without some trouble.
Even more sophisticated - insert some extra error flag. You could do
anything you like. ;-)
In case you detect some error, the calling function can abort - as it
does now when zero articles are received. You could also insert some
"retry" or something: It's up to you... ;-)
> i checked the logs carefully and found that mostly the
> gmane.comp.sysutils.supervision.general group was responsible
> for my problem, so i tricked leafnode by removing its entry in
> news/interesting.groups/. voila: hundreds of new articles from gmane.org
> showed up, so did the missing articles from the leafnode group.
That's gonna happen again and again. Next time, another group has one
(later on moved) article, next time gmane offers you only articles with
423, getchnews will quit again - until ... until you update to a fixed
That's why I hacked around this bug. I just don't want to give a warrant
for anything. I'm not deep into leafnode/fetchnews code and I'm not an
PS: I always speak of one article not retrieved. The same thing happens,
when there are more articles, that all can not be fetched.
leafnode-list mailing list