Re: [leafnode-list] fetchnews and logrotate?

[Matthias Andree <matthias.andree@xxxxxx>]

Mike Vanecek schrieb am 2004-01-19:

> On Mon, 19 Jan 2004 22:50:08 +0100, Matthias Andree wrote
> > There is no code in fetchnews 1.9.49 that could cause such a change, 
> > no addition/subtraction of 9 or 10 to be found.
> > 
> > This has all looks of a hardware fault: CPU, RAM, bus, or, if the
> > machine is under memory pressure and swaps, also disk controller/cabling
> > etc.
> 
> Just for the heck of it I tried all the way back to .45. Did not see any real
> difference. I did rebuild .49 from source and reinstall it. Also, the news log
> rotation was cleaned. (I put in create_all_links = 1 in config for a different
> reason.)

Well, it if wasn't for two particular bits (8+1 or 8+2) that got
flipped, I might have considered compiler faults (optimizer bugs
usually).

> One would think that if it were hardware, it would be showing up in other areas?

Depends on how "large" the problem is. I have seen several cases. One
machine, an AMD Duron 800 with two memory modules in a Gigabyte 7ZX  or
7ZXR would randomly crash or kill a process, even with most conservative
BIOS settings. Removing the module with the lower capacity fixed this
instantly, although memtest never found anything. That's the tiny fault
that is very annoying and hard to find. A Pentium II 400 machine
started capitalizing every fouth byte in a text, corrupted its file
systems and so on, and although the error was plain to see, recovery
involved re-installing the system. In between is an Athlon MP dual
machine that hangs up once in a while. CPU reporting reports a
temperature difference of 20 K between the two identical processors,
water cooled.

> One theory ... if one starts fetchnews while the update process is still
> running, could that cause a problem?

It _should_ not. The parent process hands over the lock file to the
update process.

> After all my looking, things seem to be a little better, but still see a few
> kills:
> 
> Jan 19 21:15:46 www fetchnews[13016]: leafnode 1.9.49.rel: verbosity level is 0
> Jan 19 21:15:47 www fetchnews[13016]: connected to 216.40.30.68:119, reply: 200
> Jan 19 21:15:48 www fetchnews[13016]: news-west.newscene.com: 0 articles posted
> 
> Jan 19 21:15:48 www fetchnews[13016]: Reading server info from
> /var/spool/news/leaf.node/news-west.newscene.com
> 
> Jan 19 21:15:49 www fetchnews[13016]: alt.os.linux.redhat: considering
> articles 31972 - 31973
> Jan 19 21:15:49 www fetchnews[13016]: alt.os.linux.redhat: killed 31972
> (<Uk5YGebhcevk7589E143XVbS1SMt8jMM@xxxxxxxxxxxxxxx>), already fetched before
> Jan 19 21:15:49 www fetchnews[13016]: alt.os.linux.redhat: killed 31973
> (<pan.2004.01.19.20.04.48.96324@xxxxxxx>), already fetched before
> Jan 19 21:15:49 www fetchnews[13016]: alt.os.linux.redhat: 0 articles fetched
> (to 10115), 2 killed

> *** Why does it consider this range and then find they were already fetched?

These are crossposted articles, the first to
Newsgroups: comp.os.linux.advocacy,alt.os.linux,alt.os.windows-xp,alt.os.linux.suse,alt.os.linux.redhat

the second to:
Newsgroups: comp.os.linux.advocacy,alt.os.linux,alt.os.windows-xp,alt.os.linux.suse,alt.os.linux.redhat

If any of the other groups have been fetched earlier, then you'll see
these messages. See if you have more than one of these groups in
interesting.groups, and if so, everything is fine.

> Is this just the nature of the way things work?

That is likely.

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95
-- 
_______________________________________________
leafnode-list mailing list
leafnode-list@xxxxxxxxxxxxxxxxxxxxxxxxxxxx
http://www.dt.e-technik.uni-dortmund.de/mailman/listinfo/leafnode-list
http://leafnode.sourceforge.net/