rosenblg@acf3.nyu.edu (Gary J. Rosenblum) (12/29/90)
i'm running Cnews with the current patchlevel, and nntp 1.5.10; ever since i upgraded to 1.5.10, i see hundreds of the following messages in my log file each night: Dec 27 03:25:04 localhost nntpxmit[11519]: acf5.nyu.edu xfer: Error 0 Dec 27 03:52:49 localhost nntpxmit[12382]: spunky.nyu.edu xfer: Bad file number Dec 27 04:04:28 localhost nntpxmit[12603]: exchange.gba.nyu.edu xfer: Error 0 Dec 27 04:09:21 localhost nntpxmit[12902]: acf5.nyu.edu xfer: Error 0 Dec 27 04:12:54 localhost nntpxmit[12943]: anyway.nyu.edu xfer: Error 0 Dec 27 04:25:51 localhost nntpxmit[13150]: pluto.dss.com xfer: Error 0 Dec 27 05:25:47 localhost nntpxmit[15080]: pluto.dss.com xfer: Error 0 Dec 27 06:22:31 localhost nntpxmit[17029]: pluto.dss.com xfer: Error 0 Dec 27 07:24:19 localhost nntpxmit[18887]: pluto.dss.com xfer: Error 0 Dec 27 07:25:32 localhost nntpxmit[18930]: acf5.nyu.edu xfer: Error 0 Dec 27 07:31:09 localhost nntpxmit[19178]: polyof.poly.edu xfer: Error 0 Dec 27 07:39:22 localhost nntpxmit[19319]: acf5.nyu.edu xfer: Error 0 Dec 27 07:42:50 localhost nntpxmit[18140]: rna.rockefeller.edu xfer: Bad file number Dec 27 07:49:36 localhost nntpxmit[19881]: spunky.nyu.edu xfer: Bad file number Dec 27 07:54:21 localhost nntpxmit[19993]: acf5.nyu.edu xfer: Error 0 i haven't gone thru the source yet, since i figured someone out there must have seen these messages. Any clues? gary Gary J. Rosenblum UNIX Systems Manager rosenblg@nyu.edu New York University gary@nyu.edu -- Gary J. Rosenblum UNIX Systems Manager rosenblg@nyu.edu New York University gary@nyu.edu
sfreed@triton.unm.edu (Steven Freed CIRT) (12/29/90)
In article <1990Dec28.234730.8332@cmcl2.nyu.edu> rosenblg@acf3.nyu.edu (Gary J. Rosenblum) writes: >i'm running Cnews with the current patchlevel, and nntp 1.5.10; ever since >i upgraded to 1.5.10, i see hundreds of the following messages in my log >file each night: > >Dec 27 03:25:04 localhost nntpxmit[11519]: acf5.nyu.edu xfer: Error 0 >Dec 27 03:52:49 localhost nntpxmit[12382]: spunky.nyu.edu xfer: Bad file number >Dec 27 04:04:28 localhost nntpxmit[12603]: exchange.gba.nyu.edu xfer: Error 0 etc. etc.. No clues, but we have been experiencing the same problem here. It is wierd in the fact that it happens when connecting to some sites (almost) all the time, and just occasionally on others. It seemed to clear up for a while a few of weeks ago, and now it's back. -- Thanks, Steve. sfreed@ariel.unm.edu
louie@sayshell.umd.edu (Louis A. Mamakos) (12/29/90)
In article <1990Dec28.234730.8332@cmcl2.nyu.edu> rosenblg@acf3.nyu.edu (Gary J. Rosenblum) writes: >i'm running Cnews with the current patchlevel, and nntp 1.5.10; ever since >i upgraded to 1.5.10, i see hundreds of the following messages in my log >file each night: > >Dec 27 03:25:04 localhost nntpxmit[11519]: acf5.nyu.edu xfer: Error 0 <rest deleted> If you look at your NNTP batch files, you'll also notice some weirdness going on there too. We noticed that the last few entries in the NNTP batches didn't have the message id listed. I spent *hours* looking at relaynews, since its the only program that writes batch files, right? Wrong. We had this problem and I finally tracked it down to nntpxmit failing to transmit a certain class of articles; namely those that had DEL characters imbedded in the text. It looks like the check for a -1 return from writing a character to the network was being triggered by attempting to transmit the DEL character, which was probably being sign extended. Error 0 is being reported because, being that no actual error occurred, errno was still 0. Nntpxmit then helpfully re-writes the batch file with the entry of the article in question stuck at the end. Grrr... louie
fletcher@cs.utexas.edu (Fletcher Mattox) (01/01/91)
In article <pst.662588576@ack.Stanford.EDU> pst+@ir.Stanford.EDU (Paul Traina) writes: >If you look at your out-bound news, and see which messages are punting, you >will notice that each one that fails has a ^? (delete) in it. The messages which passed through here actually had the eighth bit turned on, 0xff. This appears as DEL, 0x7f, in many pagers and editors. Some (broken) versions of putc() will extend the sign and return -1. If so, the correct fix, in my opinion, is in putc() and not in your NNTP transfer program.
emv@ox.com (Ed Vielmetti) (01/01/91)
In article <16363@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
The messages which passed through here actually had the eighth
bit turned on, 0xff. This appears as DEL, 0x7f, in many pagers
and editors. Some (broken) versions of putc() will extend the
sign and return -1.
There's comments in the ultrix (mips) 4.1 stdio.h saying that putc()
was changed in 09 Nov 1989 to properly handle this case; I take that
to mean that early mips ultrix might have had it broken (I'm fuzzy on
dates). It would be useful to know some more details of the systems
where nntp fails (name, os level and release date, etc.)
--Edfletcher@cs.utexas.edu (Fletcher Mattox) (01/01/91)
In article <EMV.90Dec31135407@crane.aa.ox.com> emv@ox.com (Ed Vielmetti) writes: >In article <16363@cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes: > The messages which passed through here actually had the eighth > bit turned on, 0xff. This appears as DEL, 0x7f, in many pagers > and editors. Some (broken) versions of putc() will extend the > sign and return -1. > >There's comments in the ultrix (mips) 4.1 stdio.h saying that putc() >was changed in 09 Nov 1989 to properly handle this case; I take that >to mean that early mips ultrix might have had it broken (I'm fuzzy on >dates). It would be useful to know some more details of the systems >where nntp fails (name, os level and release date, etc.) Here's an example of a broken, sign-extending, putc: #define putc(x,p) (--(p)->_cnt>=0? ((int)(*(p)->_ptr++=(unsigned)(x))):_flsbuf((unsigned)(x),p)) As best I can tell, this was present in early BSD stdio.h and was fixed between 4.2 and 4.3. I'm not sure how quickly it found its way into other vendors' BSDish products, but I notice it was fixed as far back as SunOS 3.2, and that it was broken in Dynix 3.0.4, and fixed in Dynix 3.0.14.