janick@crk56.bnr.com (Janick Bergeron 1617964) (10/17/89)
I get a bunch of .inaXXXXX and .araXXXXX (where 'XXXXX' is a 5 digit number, looks like mktemp(3) filenames to me) left in the news SPOOLDIR. Any idea why ?
clewis@ecicrl.UUCP (Chris Lewis) (10/19/89)
In article <79@crk56.bnr.com> janick@bnr.ca writes: >I get a bunch of .inaXXXXX and .araXXXXX (where 'XXXXX' is a 5 digit number, >looks like mktemp(3) filenames to me) left in the news SPOOLDIR. >Any idea why ? What version or patch level of news are you running? There's a plethora of versions and revisions out there, and without such information most people haven't a hope in hell of being able to help you. Chances are they won't have the slightest idea what you're talking about. But, what the hey, it took almost 10 years of kicking and screaming to get BNR on the net, so we'll give you a little leeway ;-) Anyhow, you're in luck this time.... I recognize this bug (this should perhaps be in a "monthly news software bug posting" perhaps?) and the version. You are running B-news, probably patch level 14, possibly 13. This is something to do with cancel messages dropping core by walking off the end of a buffer. Patch 15 repaired this problem, but the following two liner will fix *this* problem without having to go through doing a patch 15, 16 and 17 upgrade. Find your copy of control.c, circa line 690: > if (!su && STRNCMP(whatsisname, poster, strlen(poster))) { > error("Not contributor: posted by %s, and you are %s", poster, whatsisname); > } > > (void) unlink(nfilename); > p = q+1; > } > #endif /* !NFSCLIENT */ > return 0; > } immediately *after* the unlink, insert the following two lines: > if (q == NULL) > break; Rebuild, and good luck! -- Chris Lewis, Elegant Communications Inc. UUCP: {uunet!mnetor, utcsri!utzoo, uunet!attcan!lsuc, yunexus}!ecicrl!clewis Moderator of the Ferret Mailing List (ferret-request@eci386) Phone: (416)-294-9253
cathyf@rice.edu (Catherine A. Foulston) (10/21/89)
In article <716@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: >In article <79@crk56.bnr.com> janick@bnr.ca writes: > >>I get a bunch of .inaXXXXX and .araXXXXX (where 'XXXXX' is a 5 digit number, >>looks like mktemp(3) filenames to me) left in the news SPOOLDIR. > >>Any idea why ? > >What version or patch level of news are you running? > >Anyhow, you're in luck this time.... I recognize this bug (this >should perhaps be in a "monthly news software bug posting" perhaps?) and the >version. You are running B-news, probably patch level 14, possibly 13. > >This is something to do with cancel messages dropping core by >walking off the end of a buffer. Patch 15 repaired this problem, but >the following two liner will fix *this* problem without having to >go through doing a patch 15, 16 and 17 upgrade. [patch deleted - it consisted of adding two lines.] >Chris Lewis, Elegant Communications Inc. >UUCP: {uunet!mnetor, utcsri!utzoo, uunet!attcan!lsuc, yunexus}!ecicrl!clewis I have a similar thing, but it isn't from cancel dumping core, I don't think. I have SPOOLDIR/.tmp which is full of .inaXXXXX and other forms. There are 8000 of them in there. They are taking up 50 Meg. A lot of them seem to be comp.mail.maps type stuff although not all of them. I also have .bad, which has ~300K and .rnews which is empty. What are these things for? Especially the .tmp - that is a lot of disk space! I cleaned out a whole bunch last time I recompiled news, and they're back now. My cancel does dump core, but I have not figured out why. It never works from a newsreader and it dumps core when you invoke it directly. I haven't had a chance to check the code to see why it doesn't work. I had read that a particular combination of option settings would cause it not to work, but haven't figured out what they are. Oh yeah, I am running B 2.11.18 and had these problems when I started with 2.11.17. I do have the patch given above already installed. Any more ideas, anyone? Cathy cathyf@rice.edu
clewis@eci386.uucp (Chris Lewis) (10/25/89)
In article <2249@brazos.Rice.edu> cathyf@brazos.rice.edu (Catherine A. Foulston) writes: |In article <716@ecicrl.UUCP> clewis@ecicrl.UUCP (Chris Lewis) writes: | |>This is something to do with cancel messages dropping core by |>walking off the end of a buffer. Patch 15 repaired this problem, but |>the following two liner will fix *this* problem without having to |>go through doing a patch 15, 16 and 17 upgrade. |I have a similar thing, but it isn't from cancel dumping core, I don't |think. I have SPOOLDIR/.tmp which is full of .inaXXXXX and other forms. |There are 8000 of them in there. They are taking up 50 Meg. A lot of |them seem to be comp.mail.maps type stuff although not all of them. |I also have .bad, which has ~300K and .rnews which is empty. What are |these things for? This sounds similar, because most if not all comp.mail.maps postings contain "Supersedes:" headers which are effectively the same as a cancel. You may want to investigate your sources to make *sure* that the two lines of code that I suggested is *really* in your control.c. Ditto any separate Supersedes: handling. It's just possible that some sort of change to your control.c broke patch 15 in this area. What kind of system are you running? This stuff would probably be pretty sensitive regarding the type of history that you're using. SPOOLDIR/.rnews is where incoming news gets spooled to if you have SPOOLNEWS defined, or rnews starts while expire is running. They get cleaned out when "rnews -U" gets run (You have it cron'd somewhere I hope? Tho, expire usually fires it off by itself at the end of its run). This should be empty after a successful rnews -U run. SPOOLDIR/.bad is where batches get thrown if certain categories of error occur whilst unbatching. I *think* the usual cause for these are broken batches sent to you by your feeds. SPOOLDIR/.tmp: When rnews starts up, it checks its standard input to see if it's a batch. If so, it popens a pipe with "compress -d", shovels the batch thru it, reading back the result, which is broken up into separate files in SPOOLDIR/.tmp (over simplification, but never mind), which rnews forks off copies of itself to read individually. The code is *incredibly* grotty, and is probably cause for the extremely lousy performance of the forked rnews on big articles (eg: > 1 minute of CPU for articles > 32K on a 3b1) By the way, the cancel bug in patch level 14 is *relatively* harmless, because by the time rnews upchucks, the article *has* been cancelled, and since it's only working on *one* article at the time, you haven't lost anything. Except possibly an update to history (which doesn't matter with a cancel anyways). Though, you might want to confirm that map articles (Supersedes headers) have actually made it to SPOOLDIR/comp/mail/maps. -- He's a consultant: | Chris Lewis, Elegant Communications Inc. Lend him your watch | UUCP {uunet!attcan,utzoo}!lsuc!eci386!clewis and he'll tell you the time. | Moderator of the Ferret mailing list. Don Munroe, Cosmic Commander|