> >> I just got 0.88.1UL installed and have found a problem. Trn no longer > >> works as it now fails and exits when it checks for new groups with > >> > >> 500 not implimented yet. annoy nntpcache@nntpcache.org if you need this feature > >> > >> All of these worked fine with 0.87.9UL. I do have two non-overlapping feeds, > >> but I have had that same config for the last several versions. > > > >Actually, they didn't work fine, they just passed the 'newgroups' command > >through to whichever server was current and gave back the response. This is > >fine if you're only caching from one server,but produces incorrect output if > >NNTPCache is configured to read more than one server.It requires special code > >to be written to send the 'newgroups' command to all servers then merge the > >results, which is no big deal since it's the same as merging active files and > >all the code is there already. > > By 'worked fine' I just meant they didn't send error codes to the readers. > While a working multi-server newgroup would be nice, I think the old behavior > was nicer than the current error code. I'll hack together the multi-server newgroups code sometime in the next few hours. Should be included by the 0.88.3 release, whenever that will be. As for why the current release has it returning an error, I have no idea. Proff did it! Honest! It wasn't me! > Once I get trn working again, I'm going to try to figure out why it > can't chase xrefs with nntpcache (cross-posted articles are not marked > as read in the other groups). My usual method for tracking these things down is: telnet localhost 119 | tee nntpcache.out blah blah blah quit telnet real.newsserver 119 | tee server.out blah blah blah quit diff server.out nntpcache.out If diff fails to show any difference between the files (apart from the obvious ones that should be there like the welcome message), then the problem probably has something to do with nntpcache not correctly sending \r\n at the end of every line. I've noticed some readers tend to barf if this isn't quite right, despite the fact that I've seen NNRPD sending out lines that weren't always correct in this regard. NNTPCache should correct those sorts of things. > I'm also getting quite a few syslog messages like (in decreasing order of > frequency): > nntpcache.c:643: Illegal seek: Client disconnected before QUIT > nntpcache.c:643: No such file or directory: Client disconnected before QUIT > nntpcache.c:643: Broken pipe: Client disconnected before QUIT > nntpcache.c:643: File exists: Client disconnected before QUIT > They may be a result of someone canceling an article read in progress. Line 643 of nntpcache.c gets invoked if nntpcache goes to get the next command and finds the client isn't there any more. It used to just say 'client went away'. This isn't an error condition as far as the o/s is concerned, so the error string is still set to whatever it was last set to when the o/s really did return an error from something. The logging macros that Proff wrote always include the current error string in any syslog writes they generate, but in this case it isn't particularly useful, and in fact, misleading, so we should change it. > frank > -- > Frank Smith -- System Administrator E-mail: fsmith@spec.com > Systems & Processes Engineering Corp. (SPEC) Voice:(512) 306-1100 x154 > 401 Camp Craft Road Fax: (512) 306-1122 > Austin, TX 78746-6558 Web: http://www.spec.com > -- Luke Bowker, puke@suburbia.net, puke@deakin.edu.au Suburbia Public Access Network Site Sysadmin "Don't try to understand. Knowing you, I'm probably wrong" - D. Mustaine
