cudep@warwick.ac.uk (Ian Dickinson) (10/25/90)
I've been contentedly using trn ever since release date, and applied
the first patch when it came (quite some time ago.)
Recently, I've been noticing the problem which used to be in rn,
when the number of groups was larger than MAXRCLINE from common.h.
But it is certainly not the same cause.
Ie, I get this complaint from trn:
******** 1 unread article in news.software.nntp--read now? [+ynq] guw.mug
Newsgroup uw.mug does not exist!
******** 1 unread article in news.software.nntp--read now? [+ynq]
But my setup defines the following which I think is the default:
#define MAXRCLINE 1500
#define HASHSIZ 1693
which is much more than active or my newsrc:
$ wc -l /usr/local/lib/news/active .newsrc
1075 /usr/local/lib/news/active
1046 /home/clover/cu/dep/.newsrc
The group does exist but is not in my newsrc
$ grep uw.mug /usr/local/lib/news/active
uw.mug 0000000000 00001 m
I haven't tried very hard to fix this yet, cos I haven't had time.
Any helpers out there?
Cheers,
--
\/ato. Ian Dickinson. GNU's feelin' horny. Kunst und Wahnsinn.
vato@warwick.ac.uk Sabeq. Mind the gap!
vato@tardis.cs.ed.ac.uk
gdd046@cck.cov.ac.uk "I know what you sell - I don't want to buy!"cudep@warwick.ac.uk (Ian Dickinson) (10/26/90)
In article <1990Oct25.112816.27533@warwick.ac.uk>, I wrote: >Recently, I've been noticing the problem which used to be in rn, >when the number of groups was larger than MAXRCLINE from common.h. >[DELETED] >I haven't tried very hard to fix this yet, cos I haven't had time. Well I've got it working again, but I don't know what the problem was. I tried killing mthreads and restarting it, and it all worked fine. It had been running for a long time (999:99 with ps), so it may be hard to recreate the problem. But be warned - there may be a problem with mthreads. Sorry I can't offer any more info than this :-( -- \/ato. Ian Dickinson. GNU's feelin' horny. Kunst und Wahnsinn. vato@warwick.ac.uk Sabeq. Mind the gap! vato@tardis.cs.ed.ac.uk gdd046@cck.cov.ac.uk "I know what you sell - I don't want to buy!"
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/26/90)
>Well I've got it working again, but I don't know what the problem was. >I tried killing mthreads and restarting it, and it all worked fine. >It had been running for a long time (999:99 with ps), so it may be hard >to recreate the problem. But be warned - there may be a problem >with mthreads. Sorry I can't offer any more info than this :-( While I doubt this is the problem, be sure to run "mthreads -e" now and then. -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us
asbuilt@sjrpp.UUCP (SJRPP CAD Drafting Staff) (10/30/90)
In article <44*_H2&@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes)
:-) >Well I've got it working again, but I don't know what the problem was.
:-) >I tried killing mthreads and restarting it, and it all worked fine.
***stuff deleted***
:-) While I doubt this is the problem, be sure to run "mthreads -e" now and
:-) then.
I have the following 2 lines in my "news" crontab:
23 5,7,9,11,13,15,17,21,23,1,3 * * * /usr/lib/news/trn/mthreads >/dev/null
23 19 * * * /usr/lib/news/trn/mthreads -e >/dev/null
(Never have any problems)
--
CADD Drafting Staff UUCP:...gatech!uflorida!unf7!sjrpp!asbuilt
St. Johns River Power Park -------- Technical Services Deptartment
Jacksonville, FL 32226 PHONE:(904)751-7835davison@dri.com (Wayne Davison) (10/31/90)
Ian Dickinson (cudep@warwick.ac.uk) wrote: > I tried killing mthreads and restarting it, and it all worked fine. > It had been running for a long time (999:99 with ps), so it may be hard > to recreate the problem. But be warned - there may be a problem > with mthreads. There is a known problem in the active2 truncation code -- the variable truncate_len does not get reset to -1 after being used. I'm not certain that this was your problem, but this will be fixed in trn patch #2. (Don't hold your breath, though, I'm still recovering from an auto accident.) -- \ /| / /|\/ /| /(_) Wayne Davison (_)/ |/ /\|/ / |/ \ davison@dri.com (W A Y N e) ...!uunet!drivax!davison
cudep@warwick.ac.uk (Ian Dickinson) (11/02/90)
In article <44*_H2&@b-tech.uucp> zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) writes: >>I tried killing mthreads and restarting it, and it all worked fine. >>It had been running for a long time (999:99 with ps), so it may be hard >>to recreate the problem. But be warned - there may be a problem >>with mthreads. Sorry I can't offer any more info than this :-( >While I doubt this is the problem, be sure to run "mthreads -e" now and >then. I run mthreads in daemon mode with the following options: mthreads -v -a -d02 -e0500 This normally works fine..... I forgot to mention in my previous article, that killing and restarting didn't quite do the jobe properly.... mthreads noticed that there were new groups, but didn't thread them even though I run with the -a option. I fixed it with the following sequence: mthreads -k mthreads -f mthreads -v -a -d02 -e0500 Whilst it was 'misbehaving' it also refused to follow the -d02 option, and used the default -d10. -d05 worked as advertised. After restarting, -d02 worked fine. Strange times we live in seems.... -- \/ato. Ian Dickinson. GNU's feelin' horny. Kunst und Wahnsinn. vato@warwick.ac.uk Sabeq. Mind the gap! vato@tardis.cs.ed.ac.uk gdd046@cck.cov.ac.uk "I know what you sell - I don't want to buy!"
spike@world.std.com (Joe Ilacqua) (01/15/91)
For the third time trn has over flowed one of my disks
writting:
<time stamp> ** interrupt 11 **
to "mt.log".
Does anyone have a fix? Previously it was suggested that this
happens when 'mthreads' can write a thread file, but that is not the
case here.
If there is no fix, I think I will remove 'trn', it is not
worth this kind of hassle.
->Spike
--
The World - Public Access Unix - +1 617-739-9753 24hrs {3,12,24,96,192}00bpszeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (01/15/91)
> For the third time trn has over flowed one of my disks >writting: > ><time stamp> ** interrupt 11 ** > >to "mt.log". > > Does anyone have a fix? Previously it was suggested that this There are two things (actually more) that need fixing. One it to handle sigsegv better and two is to remove any thread files that causes it (someone gave me this patch but I didn't save their name). It's available via ftp from ais.org (pub/mthreads.c). We need someone to go through and really fix some of these bugs with mthreads and nntp. There is also an occasional problem with mthreads (via nntp) getting groups confused (ie, the database for one group actually applies to another). -- Jon Zeeff (NIC handle JZ) zeeff@b-tech.ann-arbor.mi.us