sjg@melb.bull.oz.au (Simon J Gerraty) (10/06/90)
I am running C News (patched to 25 May 1990), on a System V machine (Bull DPX/2 340). The system is fed via NNTP if that matters. Relaynews appears not to be updating the active file. The history file does get updated and the logs appear normal. -rw-rw-r-- 1 news daemon 22364 Oct 4 14:05 active -rw-rw-r-- 1 news daemon 22364 Oct 2 17:10 active.old -rw-rw-r-- 1 news daemon 168 Oct 2 17:10 active.times -rw-rw-r-- 1 news daemon 0 Oct 5 08:10 errlog -rw-rw-r-- 1 news daemon 0 Oct 4 08:10 errlog.o -rw-rw-r-- 1 news daemon 84 Oct 4 03:05 errlog.oo -rw-rw-r-- 1 news daemon 0 Oct 2 08:10 errlog.ooo -rw-rw-r-- 1 news uucp 1041455 Oct 5 13:05 history -rw-rw-r-- 1 news uucp 64 Oct 5 13:06 history.dir -rw-rw-r-- 1 news uucp 480044 Oct 5 13:06 history.pag -rw-rw-r-- 1 news daemon 37453 Oct 5 13:06 log -rw-rw-r-- 1 news daemon 3152 Oct 4 16:05 log.o log and history both reflect the last incomming news. active is untouched since the day before (when I did `touch active`). I have used newsbin/expire/recovact to ensure that the active file did indeed reflect the current state of /usr/spool/news - hence the active.old file. Apart from the fact that active not being updated indicates a problem, it seems to cause nnmaster (nn6.4) to not collect new news which is why it did the `touch active`. I've looked through the files in cnews/notebook and can't find any indication of probable cause. So far I have not spotted anything in relay/relaynews.c either. Notes about this system: Does not grok #!/bin/sh, I have put the necessary magic at the start of all shell scripts (I think:-) to get around this. It needs and uses setnewsids with no apparent problem. Any help would be appreciated. -- Simon J. Gerraty <sjg@melb.bull.oz.au> #include <disclaimer,_witty_comment>
henry@zoo.toronto.edu (Henry Spencer) (10/07/90)
In article <1990Oct6.004103.2076@melb.bull.oz.au> sjg@melb.bull.oz.au (Simon J Gerraty) writes: >Relaynews appears not to be updating the active file. The >history file does get updated and the logs appear normal. This gets the nod, I think, for "weirdest problem yet". One thought does come to mind... Modern active files exceed 32KB. The "big" variant of the active-file code tries to rewrite the whole file in one gulp (one fwrite(), to be precise). If you specified a large address space, but your fwrite() takes signed 16-bit size parameters, this could result in a failure. I would expect a complaint about this, but maybe something else is wrong too... -- 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