Upon a small testing period of nntpcache, I'm seeing the following
possible bugs in version 2.3.2.1 running on Solaris 2.6/x86.
When I collect stats from nntpcache via the following method, I recieved
the below segfault: ( echo 'article <stats@nntpcache>' ; sleep 3 ) |
telnet localhost 119
May 4 19:11:41 news1 nntpcache-client[11687]: sockets.c:427: <- article
<stats@nntpcache>
May 4 19:11:41 news1 nntpcache-client[11687]: nntpcache.c:208:Bad file
number: SIGSEGV!
Apparently nntpcache isn't handling this in the best manner?
--
May 4 19:03:01 news1 nntpcache-nocem[11634]: nocem.c:239: article 371100
yeilded 30 new msgsid's and 0 duplicates (already classified msgid's)
May 4 19:03:01 news1 nntpcache-nocem[11634]: nntpcache.c:208: SIGSEGV!
May 4 19:03:01 news1 nntpcached[11634]: clean shutdown with error 1.
dumping core for debug analysis
May 4 19:05:27 news1 nntpcached[11582]: nntpcache.c:400: starting nocem task
May 4 19:05:27 news1 nntpcache-nocem[11638]: nocem task awakening
May 4 19:05:27 news1 nntpcache-nocem[11638]: nocem.c:344: no new articles
in 'news.lists.filters' on 'library.airnews.net.'
May 4 19:05:27 news1 nntpcache-nocem[11638]: nocem task retiring
May 4 19:05:27 news1 nntpcached[11638]: clean shutdown
After this, 'nntpcache-nocem' no longer awakens to check for new articles
in 'news.lists.filters' ever.
--
As another poster mentioned:
> They read some groups, and catch up so that there are no new articles
> in these groups. A little later (just a few minutes) they get their
> reader to "rescan" their subscribed groups. The index still says there
> are 0 unread articles in these groups BUT on entering one such group
> there may be a few new articles in there!
I'm also seeing this behavior with tin.
Anyone know of any fixes or comments to these problems I've experienced?
---
Mike Wade * Senior System Administrator * Chattanooga Data Connection, Inc.
mwade@cdc.net * http://www.cdc.net/~mwade/ * 423-266-3369 x223
