|
Grex > Info > #30: News Problems (trn, rn, general Usenet questions) | |
|
| Author |
Message |
jeffk
|
|
News Problems (trn, rn, general Usenet questions)
|
Apr 4 07:41 UTC 1993 |
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. |
robh
|
|
response 1 of 41:
|
Apr 4 11:37 UTC 1993 |
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!
|
popcorn
|
|
response 2 of 41:
|
Apr 4 13:57 UTC 1993 |
This response has been erased.
|
srw
|
|
response 3 of 41:
|
Apr 4 15:02 UTC 1993 |
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.
|
mju
|
|
response 4 of 41:
|
Apr 4 17:13 UTC 1993 |
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.
|
kentn
|
|
response 5 of 41:
|
Apr 4 19:49 UTC 1993 |
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?
|
rcurl
|
|
response 6 of 41:
|
Apr 5 03:13 UTC 1993 |
What does "thread" mean in the context being used here? I know how to
do it to a needle only.
|
mju
|
|
response 7 of 41:
|
Apr 5 03:43 UTC 1993 |
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.
|
mju
|
|
response 8 of 41:
|
Apr 5 04:08 UTC 1993 |
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.
|
srw
|
|
response 9 of 41:
|
Apr 5 13:26 UTC 1993 |
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.
|
kentn
|
|
response 10 of 41:
|
Apr 5 23:31 UTC 1993 |
Thanks for the "thread" file explanation, mju. That explains a lot of
what I've been seeing here and on other systems.
|
jeffk
|
|
response 11 of 41:
|
Apr 6 02:34 UTC 1993 |
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.
|
jeffk
|
|
response 12 of 41:
|
Apr 7 04:15 UTC 1993 |
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. :)
|
cwb
|
|
response 13 of 41:
|
Apr 10 21:10 UTC 1993 |
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.
|
kentn
|
|
response 14 of 41:
|
Apr 11 02:17 UTC 1993 |
(Time to entertain the .QWK file suggestion again...)
|
jeffk
|
|
response 15 of 41:
|
Apr 11 23:37 UTC 1993 |
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?
|
mju
|
|
response 16 of 41:
|
Apr 11 23:55 UTC 1993 |
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.
|
srw
|
|
response 17 of 41:
|
Apr 15 14:36 UTC 1993 |
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.
|
mju
|
|
response 18 of 41:
|
Apr 15 22:18 UTC 1993 |
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).
|
srw
|
|
response 19 of 41:
|
Apr 16 03:41 UTC 1993 |
Yes .article was intact. Thanks. It is posted now.
|
srw
|
|
response 20 of 41:
|
Apr 22 13:53 UTC 1993 |
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?
|
mju
|
|
response 21 of 41:
|
Apr 23 00:45 UTC 1993 |
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.
|
srw
|
|
response 22 of 41:
|
Apr 23 05:34 UTC 1993 |
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. :)
|
davel
|
|
response 23 of 41:
|
Apr 28 00:35 UTC 1993 |
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.
|
danr
|
|
response 24 of 41:
|
Apr 28 00:49 UTC 1993 |
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.
|