boberg@ihuxv.ATT.COM (Bruce Oberg) (05/26/87)
[i was originally going to mail this to rick, but i thought others may have insight and/or interest] until this week, all the IH machines were fed news using my own spooling shell scripts. now they all use the SPOOLNEWS option for rnews and i have a slight problem. each machine is fed new news approx every 20 minutes while rnews -U is run once at 1800 and 0200 to take advantage of non-prime CPU time. the problem is that whenever rnews -U is running, it can only get through a couple spool files before a delivery of new news comes in and rnews kills off the rnews -U. thus, rnews -U is never able to catch up on spooled news. stopping the incoming deliveries is a problem since they arrive over a rather unpredictable network. looking at inews.c, i notice that rnews tries to lock the active file in all cases. when an rnews -S (run by rnews -U) can't do the lock, 42 is returned to rnews -U and recognized by dounspool() as a signal to stop unspooling. my question: if SPOOLNEWS is set, does rnews (without a -U or -S) have to lock the lock file (subsequently killing off rnews -U)? it seems to me that rnews could spool stuff no matter who else is running. what sort of problems could there be with rnews and rnews -U running concurrently? bruce oberg IH netnews admin .!ihnp4!ihuxv!boberg
rick@seismo.UUCP (05/27/87)
Here is my interpretation of what is locking what and why. First, when expire is running, EVERYTHING else stops. This includes rnews -U. inews/rnews spool for later dequeueing by rnews -U. When expire is done, it fires up rnews -U which unspools the files that were spooled because expire was running. rnews -U just reads the spool directory (.rnews) and executes rnews -S for each file in the directory. There is a lockfile to prevent multiple rnews -U from running. However, there is no reason (planned anyway. There is always the possibility of another bug.) for one rnews -S to knock another one out of action. I think that what is happening is the expire is running during one of your queue runs, so the queue run (correctly in my opinion) is being aborted early. Note that rnews only sets a READ lock (unless you have a broken implementation of advisory locks, which System 5 does not), so 2 rnews programs should not be able to get in each others way. Expire sets a WRITE lock, so the rnews read locks should fail. ---rick