slocum@hi-csc.UUCP (Brett Slocum) (12/19/87)
I'm having a devil of a time getting 'rn' running on our Apollo network. The active file stays locked for as long as someone is running 'rn'. If a process running rn gets wedged, nobody can read news, and new news doesn't get posted. Has anyone successfully fixed this problem, and can I get a copy of the required changes? -- --Brett Slocum "Never bet with a Sicilian where Death is involved." UUCP: ...uunet!hi-csc!slocum Arpa: hi-csc!slocum@umn-cs.arpa UUCP: ...ihnp4!umn-cs!hi-csc!slocum (descending order of speed, I think)
hyc@starbarlounge.cc.umich.edu (Howard Chu) (12/21/87)
In article <39256868.805@hi-csc.UUCP> slocum@hi-csc.UUCP (Brett Slocum) writes: >I'm having a devil of a time getting 'rn' running on our >Apollo network. The active file stays locked for as >long as someone is running 'rn'. If a process running >rn gets wedged, nobody can read news, and new news doesn't >get posted. Has anyone successfully fixed this problem, >and can I get a copy of the required changes? Yes, and yes. You actually have 3 alternative solutions: 1. Set up the NNTP software on the Apollos, and replace your rn with rrn. Then the active file is only locked briefly, when the rrn first contacts the nntp server. 2. Modify your rn such that it copies the active file to a temp file, and closes the original active file. This is really the same idea as #1, but involves less installation (if you're not already running nntp). 3. Wait for SR10, when all the file locking code is supposed to work across the network. Then insert code to open the active file in shared/cowriters mode in all programs that will use it. (inews, expire, rn, readnews, etc.) Since all the news software assumes a normal Unix system with only advisory file locks, you don't need to worry about multiple writers - the software generates lock files of its own to protect against that. All you really need is a mode that allows n readers *and* 1 writer, instead of the usual n readers *xor* one writer... Here at the Computing center, I've implemented all 3, and then some. My preferred setup is a hybrid of 1 and 2, since 3 isn't possible on the SR9.7 we're currently running. I have a normal rn, not rrn, with a patch to copy the active file to a temp file at the beginning of a session. (it also updates this copy occasionally...) In addition, I've configured it to use the fake inews that's part of the NNTP package, so while all news reading is done directly with the Apollo file system, postings are all generated from a single node. (Again, this is necessary because of the problems associated with multiple locks being generated from multiple nodes. This little kludge isn't supposed to be necessary with SR10, but it works just fine.) Oh yeah - our news feed is purely NNTP, we haven't used UUCP in a while. Works well. >-- >--Brett Slocum "Never bet with a Sicilian where Death is involved." >UUCP: ...uunet!hi-csc!slocum >Arpa: hi-csc!slocum@umn-cs.arpa >UUCP: ...ihnp4!umn-cs!hi-csc!slocum (descending order of speed, I think) Send me mail if you're interested in this setup... / University of Michigan /_ , ,_. Computing Center / /(_/(__ Unix Project / '