larry@nstar.uucp (Larry Snyder) (09/25/90)
I recently added a large site with a very specific
entry in the sys file (with a hundred or so newsgroups
listed). After I updated the sys file - I started getting
bad batches (bundles) in in.coming/bad. These same
batches most always will be processed by cnews when moved
back into the in.coming directory - any ideas?
--
Larry Snyder, Northern Star Communications, Notre Dame, IN USA
{larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu}
backbone usenet newsfeeds available
Public Access Unix Site (219) 289-0282 (5 high speed lines)henry@zoo.toronto.edu (Henry Spencer) (09/25/90)
In article <1990Sep24.180726.11442@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >... After I updated the sys file - I started getting >bad batches (bundles) in in.coming/bad. These same >batches most always will be processed by cnews when moved >back into the in.coming directory - any ideas? You left out the most important fact: what, if anything, is showing up in errlog to explain those batches? There is also a pervasive illusion that re-running a batch and having it work fine tells you something. Wrong. Since most batches end up in bad because of a flaw in a single article, and all articles in the batch will be rejected as duplicates when you re-run the batch, re-running it tells you *nothing* in general. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
larry@nstar.uucp (Larry Snyder) (09/26/90)
henry@zoo.toronto.edu (Henry Spencer) writes: >In article <1990Sep24.180726.11442@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >>... After I updated the sys file - I started getting >>bad batches (bundles) in in.coming/bad. These same >>batches most always will be processed by cnews when moved >>back into the in.coming directory - any ideas? >You left out the most important fact: what, if anything, is showing up >in errlog to explain those batches? relaynews: error writing `L', probably the disk filled relaynews: error writing `L', probably the disk filled relaynews: error writing `L', probably the disk filled >There is also a pervasive illusion that re-running a batch and having it >work fine tells you something. Wrong. Since most batches end up in bad >because of a flaw in a single article, and all articles in the batch will >be rejected as duplicates when you re-run the batch, re-running it tells >you *nothing* in general. the above message is bogus - I have plenty of disk space -- -- Larry Snyder, Northern Star Communications, Notre Dame, IN USA {larry@nstar, uunet!sco!romed!nstar!larry, nstar!larry@ndmath.math.nd.edu} backbone usenet newsfeeds available Public Access Unix Site (219) 289-0282 (5 high speed lines)
darcy@druid.uucp (D'Arcy J.M. Cain) (09/26/90)
In article <1990Sep25.151613.1979@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: > [...] >There is also a pervasive illusion that re-running a batch and having it >work fine tells you something. Wrong. Since most batches end up in bad >because of a flaw in a single article, and all articles in the batch will >be rejected as duplicates when you re-run the batch, re-running it tells >you *nothing* in general. Does this mean that if a batch has one duplicated article then the entire batch is thrown away? Wouldn't that cause problems with sites that get two feeds with a partial overlap? If not, perhaps you mean that the article that caused the problem is marked as received and therefore is seen as a duplicate as well. This would still mean that a redundant feed would have no chance to correct the error. Inquiring minds want to know. :-) -- D'Arcy J.M. Cain (darcy@druid) | D'Arcy Cain Consulting | MS-DOS: The Andrew Dice Clay West Hill, Ontario, Canada | of operating systems. + 416 281 6094 |
urlichs@smurf.sub.org (Matthias Urlichs) (09/27/90)
In news.software.b, article <1990Sep26.114528.24670@nstar.uucp>,
larry@nstar.uucp (Larry Snyder) writes:
<
< >You left out the most important fact: what, if anything, is showing up
< >in errlog to explain those batches?
<
< relaynews: error writing `L', probably the disk filled
< relaynews: error writing `L', probably the disk filled
< relaynews: error writing `L', probably the disk filled
<
It seems that you mistyped something in your sys file.
Check all lines with "L" in them.
< the above message is bogus - I have plenty of disk space --
<
Someone (meaning Henry and/or Geoff) should think of propagating an errno
value (sys_errlist might also be a good idea, but not everyone has it :-( )
into the error log file.
--
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330) \o)/henry@zoo.toronto.edu (Henry Spencer) (09/28/90)
In article <1990Sep26.143619.21521@druid.uucp> darcy@druid.uucp (D'Arcy J.M. Cain) writes: >Does this mean that if a batch has one duplicated article then the entire >batch is thrown away? ... No, they'll be processed just fine, but the *next* time you feed them in, they will all be duplicates. >... perhaps you mean that the article >that caused the problem is marked as received and therefore is seen as a >duplicate as well. This would still mean that a redundant feed would have >no chance to correct the error. This is true. However, it's a fundamental problem. Short of comparing the two copies byte-by-byte, there is no way to tell whether a second copy might perhaps fix something that was wrong with the first... and there is no automatic way (in general) to decide which is the fix and which is the bug. Attempting any of this is also very costly, and sites with redundant feeds normally get 2+ copies of the exact same thing. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (09/28/90)
In article <1990Sep26.114528.24670@nstar.uucp> larry@nstar.uucp (Larry Snyder) writes: >relaynews: error writing `L', probably the disk filled >... >the above message is bogus - I have plenty of disk space -- Geoff's code is being a little overoptimistic about deciding the cause of the problem. In this case, it looks very much like you've got the wrong number of fields in that new sys-file line, so the "flags" field is being taken as the batchfile name. -- TCP/IP: handling tomorrow's loads today| Henry Spencer at U of Toronto Zoology OSI: handling yesterday's loads someday| henry@zoo.toronto.edu utzoo!henry
henry@zoo.toronto.edu (Henry Spencer) (09/28/90)
In article <g$rpf2.]y3@smurf.sub.org> urlichs@smurf.sub.org (Matthias Urlichs) writes: >Someone (meaning Henry and/or Geoff) should think of propagating an errno >value (sys_errlist might also be a good idea, but not everyone has it :-( ) >into the error log file. Actually, the code tries to use sys_errlist. It's not entirely clear why he's not getting any more specific information. -- Imagine life with OS/360 the standard | Henry Spencer at U of Toronto Zoology operating system. Now think about X. | henry@zoo.toronto.edu utzoo!henry
cudep@warwick.ac.uk (Ian Dickinson) (10/04/90)
In article <1990Sep27.171401.2268@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes: >No, they'll be processed just fine, but the *next* time you feed them in, >they will all be duplicates. Whenever I have enough time to do this, I move in.coming/bad/* into in.coming. It might just give a lot of duplicates in the log file - no harm there. It may save some batches that were thrown out because of some temporary resource problem.....Real bad batches will die a horrible death. Cheers, -- \/ato. Ian Dickinson. GNU's not got BSE. Cut Cerebus some slack! vato@cu.warwick.ac.uk Plinth. vato@tardis.cs.ed.ac.uk Sabeq. gdd046@cck.cov.ac.uk "Nuke me tender, nuke me good!"