[news.software.b] Uncompressed news discarded in C News

andrew@idacom.uucp (Andrew Scott) (09/27/90)

One of our newsfeeds sends us uncompressed news.  It only amounts to perhaps
a dozen articles a day, so don't be alarmed...  Our problem is that these
batches are tossed by C news into the in.coming/bad directory for no apparent
reason.  If I compress them by hand and put them back into the in.coming
directory, they are processed with no problems.

Mail sent to news looks like:

thishost relaynews `bad/654364346' failed, status 1005 (see errlog)

Sometimes the status returned by relaynews is 1.

The strange thing about this is that there is nothing in errlog to indicate
what went wrong.  I can't see how relaynews could return a status of 1005
either.

We are running C news of 25-May-1990 on a Vax running 4.2BSD.  Has anybody
else seen behavior like this?
-- 
Andrew Scott	| mail:		andrew@idacom.uucp
		| - or -	..!uunet!ubc-cs!alberta!idacom!andrew

dan@oresoft.com (Daniel Elbaum) (10/02/90)

In <1990Sep26.205549.14138@idacom.uucp> andrew@idacom.uucp (Andrew Scott) sez:

:One of our newsfeeds sends us uncompressed news...  Our problem is that these
:batches are tossed by C news into the in.coming/bad directory for no apparent
:reason.  If I compress them by hand and put them back into the in.coming
:directory, they are processed with no problems.

:Mail sent to news looks like:

:thishost relaynews `bad/654364346' failed, status 1005 (see errlog)

:Sometimes the status returned by relaynews is 1.

:The strange thing about this is that there is nothing in errlog to indicate
:what went wrong.  I can't see how relaynews could return a status of 1005
:either.

:We are running C news of 25-May-1990 on a Vax running 4.2BSD.  Has anybody
:else seen behavior like this?

We are running fully-patched (as of 7-Sep-90) cnews on an 11/750 running
Xinu 4.3 and are having just the same symptoms.  1005 is what we get, too,
(but sometimes 1) and it *does* seem like a very strange value.  Space
doesn't appear to be a problem.  Errlog usually is empty.  We don't
have a full feed, but we get roughly 200-300 "Dear news" letters a day.
-- 
..!{uunet,sun!nosun}!oresoft!news   news@oresoft.com
-- 
..!{uunet,sun!nosun}!oresoft!news   news@oresoft.com

henry@zoo.toronto.edu (Henry Spencer) (10/03/90)

>In <1990Sep26.205549.14138@idacom.uucp> andrew@idacom.uucp (Andrew Scott) sez:
>:thishost relaynews `bad/654364346' failed, status 1005 (see errlog)

This means *something* is badly wrong, but I'm at a loss to say just what.
You might try running relaynews manually with one of the troublesome batches
as input, and seeing what the shell has to say about that status.  The high
bit indicates that the program is not just returning a non-zero exit status,
it is actually failing by being hit with some sort of signal.  That is Not
Normal, to put it mildly, and we've never seen it before.

>:The strange thing about this is that there is nothing in errlog to indicate
>:what went wrong...

Almost certainly the signal, whatever it is, is blowing relaynews away before
it can get a message out to errlog.

If you are using the stdio speedups we supply, you might try rebuilding
news without them.  It is just possible that there is some very obscure
incompatibility in your stdio that our test doesn't detect.
-- 
Imagine life with OS/360 the standard  | Henry Spencer at U of Toronto Zoology
operating system.  Now think about X.  |  henry@zoo.toronto.edu   utzoo!henry

schoch@sheba.arc.nasa.gov (Steve Schoch) (10/04/90)

In article <1990Oct3.162212.24528@zoo.toronto.edu>, henry@zoo.toronto.edu (Henry Spencer) writes:
|> You might try running relaynews manually with one of the troublesome batches
|> as input, and seeing what the shell has to say about that status.  The high
|> bit indicates that the program is not just returning a non-zero exit status,
|> it is actually failing by being hit with some sort of signal.

When you run something from the BSD csh, note that if the process dies
with SIGPIPE, csh won't say anything but "Done".  I suppose this is
because when a process pipes its output to another one a SIGPIPE exit
is "normal".

	Steve