I have a quicky:

In trn, my news lists that I have, say, 5 new unread articles to read.
When it goes into Threading...  trn ends up threading many more (450+) than
are actually present.  Each day, the 450+ grows by the number of old
articles that I've already read.

I've checked my .newsrc and according to it, articles 1-29000 have all been
read...NO HOLES.  Clearly, there is a count off somewhere that thinks I
haven't read some articles.

This all happened after the last time Grex went down for a day or so.

1) What's going on?
2) How do I fix it?  It's terribly time-consuming for it to re-thread
   what's not there.

41 responses total.

I'm no expert, but I do know a temporary solution.  Use rn instead
of trn.  It doesn't thread articles at all, and if you only have 5
articles to read, what the heck!

This response has been erased.

If there's some validity to what you said, it implies to me that a great
deal of news is getting lost. I too see hundreds of articles getting threaded,
but a much smaller number available to be selected. I'm puzzled too.

That usually indicates that the thread files for that newsgroup are
damaged or nonexistant.  That means that instead of just reading the
thread file to get the thread list, trn has to thread the group
on-the-fly.  Because of the way threads are implemented in trn, there's
no way to just thread the unread articles without having the thread
data from the read articles; if the thread file is missing or damaged,
that obviously doesn't exist, so it has to thread the whole group.
Does this happen in just some groups, or to every group?  A "fix" is
to un-thread all the groups and re-thread them, but that takes a long
time, and I'd prefer to just fix the thread files for a couple groups
if that's all that's broken.

For groups that I'm going to read straight through anyway, I usually
turn threading off in trn ("t" toggles it for each group at the top
level).

How do you create a thread file for a newsgroup?  Since the group is
subscribed to, according to trn, does this mean that some information
in the .newsrc is messed up?  I've toggled the threading on a group,
causing it to re-thread, but it still needs to do this every time I
read a group that's toggled as threaded.  Are thread files keep in
some other place?

What does "thread" mean in the context being used here? I know how to
do it to a needle only.

There are systemwide thread files stored in /news/spool/thread.files;
these are maintained by a daemon process (mthreads) and automatically
updated when new articles come in.  When you read a group with
threading turned on, trn first looks for a systemwide thread file for
that group.  If it doesn't find one, or if the thread file is corrupt,
trn forks off a subprocess (tmpthread) to create a thread file
on-the-fly.  This is a the process that prints the "Threading xx
articles..." message.

Depending on how you configure trn and mthreads, you can have
systemwide thread files for all groups, some groups, or no groups.
Since Grex is slow and disk space is easier to add than CPU, I
have systemwide thread files turned on for all newsgroups.  This uses
up about 5%-10% of the news spool space storing thread files, but
means that you shouldn't have to wait for tmpthread to thread a group
every time you go into it.  The systemwide thread files are something
that only the news administrator (i.e., me) can muck with; if they
need to be fixed for a set of groups, it's not something that a
regular user can take care of.

And, to answer Rane's question: In this context, "thread" refers
to a discussion thread, similar to a PicoSpan item.  A Usenet thread
consists of a tree of articles, with the first article in the thread
at the root, and the replies underneath it.  Because of the way
Usenet articles and distribution works, the articles that form
a discussion thread usually arrive at your site jumbled together
with articles from other threads, and sometimes even out of
chronological order.  Instead of reading articles in the order they
were received at your site, like rn does, trn groups articles by
discussion thread and allows you to read only the threads you want,
and read the articles and replies in the order they were posted.
With the many high-traffic groups on Usenet, you may not be interested
in reading all (or even most) of the articles in a group.  Using
trn, you can select threads by Subject: header, and then mark the
unselected threads as read without looking at them.

Oops.

I just figured out what the problem is.  When I installed trn 2.5,
I moved LIBDIR from /news/lib/trn to /usr/local/lib/trn.  LIBDIR
is where mthreads, the log files, and various support programs
live.  Unfortunately, I forgot to modify the rc.local and crontab
files to run mthreads and the log-cleanup program from the new
directories.  And, since I didn't remove the old software, I never
got any error messages to tell me anything was wrong.

Everything probably would have progressed as normal, with trn
using the thread files generated by the old mthreads, except that
during one of the system crashes a week ago, a stale mthreads
lockfile got created and never was removed.  Which means mthreads
hasn't been running for the past week.  Which means that the
systemwide thread files haven't been getting automatically updated.

I've fixed both problems; the new mthreads is threading all of the
groups as we speak.  Sorry for the difficulties, and sorry that
I didn't realize this earlier -- I read news locally on mudos,
so I tend not to notice problems with Grex's news software unless
they're pointed out to me.

I can confirm that it all works better now. I noticed this problem earlier
and would have notified mju sooner, except that it seemed to happen 
gradually, and I wasn't certain anything was really broken.
I'll spot something like this a lot sooner if it should happen again.

Thanks for the "thread" file explanation, mju.  That explains a lot of
what I've been seeing here and on other systems.

Thanks!  I've noticed that some of the groups came up faster and without
the usual count-off.

The explanation of threads was also very helpful.

All of my newsgroups work without the rethreading stuff, except,

   comp.os.linux


This one (for me anyway) has 440 or thereabouts number of articles that
need to be not-searched for.

Thanks for the great work so far,
-Jeff. :)

     I have so far not dived into news reading, partially because I don't
want to take up huge amounts of time on the phone.  Keeping up with
conferences here is bad enough.  Is there a way to read news locally, I
mean on my home machine?  I'd like to be able to download a file and use
it on my machine.

(Time to entertain the .QWK file suggestion again...)

If you're running Unix, I suppose you can always download the news, but I
don't know if certain groups can be stripped or not.  What's the deal
there, anyway?  Would this be of any help to grex if we just downloaded and
then went offline and later uploaded any posts we had?  I guess what I'm
asking, is if would be good to offer a limited type of server service to
those who can handle reading news on their own machines?  Is it in Grex'
interests?

Grex can handle limited outgoing newsfeeds.  Not too much, because we
really don't have the disk or modem bandwidth to do lots of major
feeds.  You'll need some kind of Usenet software on your machine
(plus UUCP software, of course).  We'd essentially be setting you
up as a leaf site.  You can get fed whatever subset of the Usenet
groups you want.

Right now, though, our main bottleneck seems to be available disk
space, not modem time.  (At least, *I* never seem to get busy signals
all that frequently, and we should be getting the 6th public dialin
installed on Monday or Tuesday.)  If people are real interested in
getting something like this going, I'll be happy to help out if
I can, but I don't see it as a real big priority right now.

Last night I had a problem posting a followup to an article with 'F' in trn.
(Yes, I am a member.)  I mailed mju a description of what happened, but was
too tired to realize that what I should probably have done is post it here.
So I am doing that now.

I wrote my whole followup and got to the send (which I issued) and then this
happened:

Send, abort, edit, or list? s
newsspool: renouncing setuid due to nonstandard `NEWSPATH' in environment
newsspool: unable to create temporary `/news/spool/in.coming/nspool.a02555'
(Per
mission denied)
/news/bin/inject/injnews: article in /u/srw/dead.article
Article appended to /u/srw/dead.article
A copy may be temporarily found in /u/srw/.article

What did I do wrong?
If something needs to be fixed, can I post it later from .article ?
how?

Apologies to Marc, who'll see this twice.

You didn't do anything wrong, I did.  It's fixed now; you can post
the article by typing "inews -h <.article" from a shell prompt
(assuming the article is still in .article).

Yes .article was intact. Thanks. It is posted now.

Two things that seem out of the ordinary now:

(1) reading rec.arts.startrek.current last night, I encountered am error
message upon entering thread selection mode. I don't remember the message
exactly, but it was something about not being able to read the threading
info, so it dropped into unthreaded mode. I would like to correct this if it
will not go away by itself.

(2) The last news delivery ended at 10:15pm last night (4/21). There has
been no connection in almost 12 hours. Is something wrong?

Yes, there is something wrong.  /h3 seems to have fragmented itself
to death, so there's no room for new files to be created (even though
there is still free space).  We will have to recreate the filesystem
before news can restart.  I'll see about doing it tonight.

Well, whenever you do get to it, Marc. thanks. It gave me chance to compose
a two-liner in agora sys problems, before I read this. :)

I'm still just starting to learn about trn, & the man is so hideously
long & slow - so I apologize for a dumb question:  Here I am, reading
along a thread.  I finish an item and go on to the next & the next, &
suddenly realize I need to reread the first one.  How do I get back to
it?  I don't think I know its item #, but I may just not have looked in
the right place - but even if I do, I don't know how to use it.  The
thread selection screen just tells me there are no previous unread items.

What I do is use the capture buffer of my comm program to allow me
to scroll back and see it.  If you're still within the same thread,
you may be able to use "P" to read a previous article, but it doesn't
always work the way you want it to.  If you do know the article number,
all you have to do is type the number and it will be recalled.

You can use the "U" command to switch between selecting read and
unread articles with the thread selector.  You can also use "U"
to enter the thread selector and select read articles while at
the newsgroup or article selection prompts.  While in a thread,
you can use the "[" and "]" commands to move around in the thread,
as well as the "{" and "}" commands and the "(" and ")" commands.
You might want to look at the trn help screens (hit "h" at any
prompt for context-sensitive help), which are more concise than
the manual page.  I will freely admit that the man page is badly
organized and poorly written in places, as well as much too long.
If you know the man macros and how to write stuff with troff, feel
free to write a better one.

Certainly not without knowing the program better.  I do use the help
screens; must have missed, or misunderstood, the U command.  Thanks,
Marc.

Is there documentation somewhere that explains the man macros?  I'd
give rewriting the trn man page a go.

man(7), I think.

Right you are.  Now, how can I get hold of the man page for  trn?

I would add that one major disincentive to using man, especially when
the man page is long, is the time spent waiting for it to come up.

The man page for trn is in /usr/local/man/man1/trn.1.

(The slowness of man pages to come up has been fixed, thanks to mju.)

Sorry, John, but it's not fixed.  I just did man trn, at a time when I'm
the only one on the system at that, and the time from "Reformatting page"
until "done" was just over 2.75 minutes.  This is unacceptable, in my
view; that is, no one will use man for something like trn on a regular
basis, under those conditions.

Well, John's announcement was just a bit premature.  catman hadn't
gotten to formatting the trn manpage when you tried it.  If
you try again, you should find that it pops up on your screen
within a few seconds.

(Sorry about the prematurity.  trn comes up quickly now.)

You're right.  My apologies.  It was effectively instantaneous, & there's
a pretty full set of people on tonight.  This will make a *big* difference
when I have problems.  Thanks very much.

  So we have room for formatted man pages now?  Great!  It *IS* a lot
faster!

I've begun using rn for a few newsgroups. It takes a long time to
bring it up, but I suffer thorugh that. After I've read all the
titles, and a few articles, in the newsgroups I follow, I enter q to
quit. *This* takes as long or longer, than it took to launch rn.
I've tried to cut this short, with ^C (and other things) but no
luck. Is there a way to escape, or is something going on that I
just have to wait for?

yep.

- Backtalk version 1.3.30 - Copyright 1996-2006, Jan Wolter and Steve Weiss